ATC, oldtool = newtool, still going for nothing to TCP TP

[sebba]

Hello,

I developed a script for my ATC system.
I also have enabled TC Auto TCP, TC Auto TLO, TLO = PTL and Skip RH Tools.
Everything seems to be as expected unless the case when I start a g-code which start with a tool which is already loaded.
At every g-code start, if oldtool = newtool, it seems The M6ATC (M6Start & M6End I think) are ignored as expected but when M6Tx appear in g-code the machine is moving to the TCP TP position, wait there for a second or two, and then back to working position.
As far as I think, if oldtool = newtool and also is a tool with repeatable holder, the machine shouldn't go (for nothing) at the TCP TP position and then back but it goes.
It is just an annoying problem, especially when the distance to TCP TP and back is larger.
There is any ways to avoid this useless movements?

I'm running latest version or Mach3, MSM 2.0.12, Win XP on Gecko 540 + 2nd LPT PCI port

Thank you,
Seb

[DaveCVI]

Hi,
Sorry, but the tool change is written such that if TCAutcoTCP is on, then the move to the TCP is made for each M6. It is not conditional on newtool / oldtool values.
Dave

[sebba]

Yes, I saw that, thanks.
There is some possibilities to temporarily disable it when m6atc is ending after newtool = oldtool?

Thank you

[DaveCVI]

HI,
In the current MSM code there is no conditional test for new=old and if the AutoTCP button is on, MSM will move to the TCP as part of the M6 sequence.
There is not an option to disable this action.
Dave

[sebba]

I understand that but what I wanted to ask is if I have the possibility to do some dooembutton inside m6atc script, to enable or disable auto tlo and so on functions if newtool = oldtool or not
I'm thinking (nothing tested yet) to make some "if" which will enable or disable these functions (buttons) when need it.
Do you think will work?
Also, why these functions are not checking if oldtool=newtool? Something like "skip rh" for measuring...
Is it my approach bad?
Thanks

[DaveCVI]

Hi,
I'm hesitant to offer a way to play with this from a user script. It if I let users control the buttons directly, (ex: AutoTCp), turning it on and off at random times could really mess up the internal MSM logic that handles the tool change sequences. The result could literally be a machine crash from MSM assuming the machine is at one location when in fact it is elsewhere.

I'd need to look at the code some to see just how dangerous this would be. Alas, I'm in the San Francisco area where everyone has been ordered to shelter in place at home for 3 weeks. That is making things around here a bit crazy and so I'm not sure when I'll have a chance to look at this more or try it out.

Dave

[sebba]

Thanks for your input, at this moment I'll let the machine to make more movements, like gym exercises, even not useful. I prefer safe than fast.
Same situation here, Romania, but for now not very restrictive. We can go to work, still...
I wish you all the best and "happy quarantine", if I'm allowed to say that

[sebba]

hello again
I played a little bit and I think I have a solution
I made new macro, to replace regular M6, and this new macro will check for newtool <> oldtool before loading M6 macros
Also, will disable TCAutoTCP, TCAutoTLO, TLO=PTL and SkipRHTool if newtool is a RH tool, before running the M6 macros and re-enable them after M6 macros end.
also, I edited the postprocessor to put M606 (the new macro) instead M6 when changing tools

for now I'm offline, it is lockdown here and I cannot test in on my machine but it seems to do the job
please check it and let me know if I omitted some important things... or if any issues can appear using this macro

Code: Select all

Option Explicit

Dim oldtool As Integer
Dim newtool As Integer

Dim tcatcp As Integer
Dim tcatlo As Integer
Dim tloptl As Integer
Dim skiprh As Integer

Dim NRH As Integer

'getting initial values
skiprh = getoemled(1726)
tloptl = getoemled(1764)
tcatlo = getoemled(1711)
tcatcp = getoemled(1709)

'looking for RH/NRH tool setting - 0 if RH tool
NRH = InStr(1, GetToolDesc(GetSelectedTool()), "NRH")

message "M606 Start"

oldtool = Getoemdro (1824) 		
newtool = GetSelectedTool()		

If newtool <> oldtool And newtool > 0 Then 

	If NRH = 0 And skiprh <> 0 Then Call RunScript("ScreenSetMacros\" & GetActiveScreenSetName() & "\" & "Masters\Scripts\Common\RHTHolders")
	sleep 50
	If NRH = 0 And tloptl <> 0 Then Call RunScript("ScreenSetMacros\" & GetActiveScreenSetName() & "\" & "Masters\Scripts\Common\TCAutoTLOFromPTL")
	sleep 50
	If NRH = 0 And tcatlo <> 0 Then Call RunScript("ScreenSetMacros\" & GetActiveScreenSetName() & "\" & "Masters\Scripts\Common\TCAutoTLO")
	sleep 50
	If NRH = 0 And tcatcp <> 0 Then Call RunScript("ScreenSetMacros\" & GetActiveScreenSetName() & "\" & "Masters\Scripts\Common\TCAutoTCP")
	sleep 50
	
	message "M6ATC Start" 

	code "M6T" & newtool
	sleep 1000
	
	'wait for M6ATC to finish	
	While getoemled(1725) <> 0
		sleep 250
		Wend
	
	message "M6ATC Ended" 
	
	'restoring initial settings	
	If tcatcp <> 0 And getoemled(1709) = 0 Then Call RunScript("ScreenSetMacros\" & GetActiveScreenSetName() & "\" & "Masters\Scripts\Common\TCAutoTCP")
	sleep 50
	If tcatlo <> 0 And getoemled(1711) = 0 Then Call RunScript("ScreenSetMacros\" & GetActiveScreenSetName() & "\" & "Masters\Scripts\Common\TCAutoTLO")
	sleep 50
	If tloptl <> 0 And getoemled(1764) = 0 Then Call RunScript("ScreenSetMacros\" & GetActiveScreenSetName() & "\" & "Masters\Scripts\Common\TCAutoTLOFromPTL")
	sleep 50
	If skiprh <> 0 And getoemled(1726) = 0 Then Call RunScript("ScreenSetMacros\" & GetActiveScreenSetName() & "\" & "Masters\Scripts\Common\RHTHolders")
	sleep 50
	
End If

message "M606 End"		              

thank you,
Seb

[DaveCVI]

Hi,
OK, you've replaced M^ wiht a custom M code, and the new Mcode checks for newtoool = oldtool and conditionally skips issuing the M6. If that works OK for you, then great!

On a different topic, I thought I'd offer some advice on using the mach3 runscript call.
In your script I see it is calling runscript and then waiting a fixed time duration before continuing. There is no need to do that since Mach3 will not return from RunScript until the called script has completed.

You might find this this little bit of code from MSM's internal utility routines interesting -

Code: Select all

Sub MSMRunScript(ByVal MSMScriptName As String, ByVal P1 As Double)
	
	' This is a wrapper that will allow one to replace the functionality of "Call Mxxxx Px". 
	' In fact this it is a bit more capable as the param is implemented as an Global MSM userspace DRO, 
	' so the script could actually put a value back in the param DRO if needed.
	' This could also be expanded to more params, but MSM only was used one param for prior MSM Mxxx macros.
	' param type choices  where double DRO or LEDs - used DROs as the more flexible approach,
	' LED parameters will be encoded within MSM as 0/1 value in the DRO.
	'
	
	Dim QFN As String
	Dim result as integer
	
	SetUserDRO(MSMRunScriptParam1DRO, P1)	' stash the param value in the allocated Global DRO

	QFN = "ScreenSetMacros\" & GetActiveScreenSetName() & "\" & MSMScriptName
	
	'MsgBox "Script to run: " & Chr(13) & "    " & QFN & Chr(13) & "Param value = " & P1
	
	result = RunScript(QFN)	' I didn't always check the return value of RS As in 3.43.2 and prior with the RS call,  it is always true - 
					' updated the Code when that got better in later versions of mach
	if result < 0 then
		' error - script was not run
		message "MSMRunScript Error " & chr(13) & _
		"Script to be run: " & Chr(13) & "    " & QFN & Chr(13) & "Param value = " & P1 & Chr (13) & _
		"Error = " & RSErrorText(result)
		
		msgbox "Script to be run: " & Chr(13) & "    " & QFN & Chr(13) & "Param value = " & P1 & Chr (13) & _
		"Error = " & RSErrorText(result), 48, "MSMRunScript Error."
	end if
End Sub

Dave

Dave

[sebba]

Hello Dave,

I tried to send you a PM but something is not OK, the message is still in outbox and not in Sent, as I think should be. Is your inbox full or...
How can I contact you directly?

Thanks,
Seb