[RRF 3.5beta2]Problem with T-1
-
Hello everyone,
My printer is a multitool so it takes a few seconds to pick up or put down a tool. When updating the board to the latest version of the firmware, when executing a T-1 with a picked up tool, it enters a loop in which it leaves the tool and then picks it up again. The solution I have found is to put a "G4 P500" in the "Tfree" files, but that problem did not exist in version 3.4.
Firmware: 3.5beta2
Web server: 3.5beta1
Board: 6HC (standalone mode)
Core XY -
@Yordan thanks for the report. That's quite a complicated tfree.g can you talk me though what its doing, especially the call to G50.g and why all the timing is required.
-
Hi Tony, thank you for your answer. What I do is make a call to my own Gcode (G43) in the Tfree file that leads me to what you see in the image of the previous message. I do it this way because I have implemented a system to leave the tool when the printer starts up in case of having the tool in the carriage, therefore I only need to have two switches configured to leave the tool.
In the file that you see (G43) I verify that the tool sensor exists so that it does not give me an error, then I equalize a variable with the current time of the machine, this is for safety, if leaving the tool takes longer than the time I specify below stops and does not continue. Then I go to some first coordinates that only bring the tool closer to its parking place, I do the final part of the route in the "While true" adding to the variable sum 0.1 each time the loop is executed and moving the X axis to the coordinate which the sum variable tells me until the parking switch is 1. This makes the last two millimeters of travel smooth and controlled. When the parking sensor is 1, I deactivate the tool clamping (M42 P0) and move the carriage to a safe coordinate.
The G50 file is its own Gcode that pauses if it's printing and an "abort" if it's not printing. -
@Yordan so without the G4 P500, could it be that this conditional:
was not evaluating correctly due to the speed at which the sensors were being read? you can do some tests echoing the state of those sensors. -
The tests:
Switch 1 = Parking switch
Switch 2 = Tool switch
-With G4 P500:
-Without G4 P500:
-
@Yordan so what does that show? It would be helpful if you explained the difference.
-
When switch 1 (parking) is 0 there is no tool, if it is 1 the tool is in the parking lot.
When switch 2 (tool) is 1 the tool is in the carriage and if it is 0 the tool is not in the carriage. seeing the echos that are set to monitor those switches, before finishing leaving the tool, and after leaving it.
The results obtained seem to indicate that when sending a T1, Tpre and Tpost are executed twice, when leaving the tool (T-1) we have two cases:- Without the delay (G4 P500) it executes Tfree and Tpost twice, it never enters the last conditional and the echo indicate so
- With the delay (G4 P500), it only executes Tfree and Tpost once and manages to enter the last conditional, also the status of the switches that the echo show us confirms the above.
Thanks in advance and if you need any more information let me know
-
@Yordan
I wonder if it might be related to the behaviour explained in this thread.
Some commands are not queued when they use a global variable as a parameter. It is likely the same when you use a local variable.
M42 is one such command.
Try putting M400 before your all of M42 and G53 calls.
