Conditional G-Code assistance
-
This post is deleted! -
Couple of quick comments. I think you are on a reasonable track, but there may be a better way. Check out M581 and M582. M581 configures an external trigger - sets up the pin you set up as a "trigger". You can use this to start an action when the trigger goes off, and you can also use M582 to check the state of your trigger.
Regarding your code for dummies question - The meta commands are a good place for a novice programmer to start - not too many capabilities, and not too many ways to do each one. I recommend making a small macro called something like "programming test.g" that you can write little bits of code in to check if it's doing what you think it should. You'll discover some things and also have great little snippets to post and ask for guidance.
In the code you posted, one "syntax" thing. (In coding, "syntax" is the grammer needed so your code will be correctly interpreted). Line 1 starts a loop. When you have a loop, there are a series of code lines that are repeated until the condition becomes false. This is called a "code block". In reprap cgode, the required syntax is that all the lines in a code block need to be indented by two spaces more than the line that started them. Everything after your "while" line is a block, and the statements after you "if" lines are each their own code block. So I think it should look like this:
while sensors.gpIn[121.io1.in].value[0]=0 ; loop to check if the probe value changes from 0 to 1000 if sensors.gpIn[121.io1.in].value[0]=1000 ; when the actuator is attached the sensor value will change to 100 break ; when sensor = 1000, end loop else if sensors.gpIn[121.io1.in].value[0]!= 0 abort "Actuator not attached, homing has been aborted"
So that's the cleaned up syntax. The way it will work (as written) is this:
when line 1 is executed, if the sensor value is exactly zero, then do lines 2-6. If sensor value is 1000, nothing will be executed. Also note that if the sensor value is 2, nothing will happen. You should probably always use a ">" or "<" instead of an "=", with the value being somewhere around the trigger value.Assuming the sensor value is 0, the very next step (happening almost immediately is to check the sensor again, and this time if is exactly 1000, break. Again,a >value is probably better here. But you also didn't give the sensor much time to change. You might want to add G4 line before the if statement.
With the "=" signs in your loop and if statements, you'll probably almost always jump right to the "else". Then, the sensor value is looked at again and if it is still 0, you abort.
I think you're order of business is something like this:
- You instruct the fw to pick up the actuator.
- You wait some time to let this happen and check to see if the actuator is connected.
3.If the actuator is connected, proceed. If not abort.
On Step 2, you have 2 choices. Option one is pick a time and after your command for step 1, add a G4 with your choice of wait time. Option 2 is to write a loop that waits for a shorter amount of time and checks each time the loop runs. This option lets you put in a long wait, but lets it finish quickly if the connection happens fast.
Something like this
var triggered = false ; create a variable to track whether the sensor has been triggered. while iterations <30 ; "iterations" is a special word in RRF gcode. It counts the number of times the code has been through this loop. G4 S1 ; pause for 1 second if sensors.gpIn[121.io1.in].value[0]=1000 : test whether the sensor is triggered set var.triggered = true ; track the fact that the actuator has been triggered. break : break says stop running around the loop immediately if !var.triggered abort
This loop will run in a circle up to 30 times, waiting 1 second on each loop. So you've got 30 seconds for your actuator to be grabbed. ANd as soon as the actuator is grabbed, the loop ends. You need the if outside the loop so that the abort will only be executed if the 30 loops happened without the trigger being detected.
-
@arnold_r_clark said in Conditional G-Code assistance:
My order of business for homing is: home X & Y, collect the actuator, home Z, Stow the actuator.
I have a somewhat similar type of removable Z probe.
I keep the Z probe attached most of the time. I remove it to start printing and re-attach it when printing is complete.
This minimizes the number of times the attach/remove process needs to be done.
Frederick
-
This post is deleted! -
@arnold_r_clark said in Conditional G-Code assistance:
The actuator is attached only once during homing/lead screw levelling then never touched again.
When is it detached?
Frederick
-
This post is deleted! -
@arnold_r_clark said in Conditional G-Code assistance:
It is attached to the head after X & Y are homed, it homes Z and then (if only homing) gets stowed back in its frame dock, if carrying out a G32 it completes that (after homing) then gets stowed.
Thanks.
And when creating or loading the heightmap, how is that handled?
Frederick
-
This post is deleted! -
@arnold_r_clark said in Conditional G-Code assistance:
For creating a height map I run a G29 with no switches this runs a mesh.g file, in that file I have it set to run the following files
M98 P"homexy.g" ; Home the X & Y axes M98 P"collectactuator.g" ; Pick up the Z probe actuator M98 P"homez.g" ; Home the Z axis M98 P"bed.g" ; Level the x3 leadscrews G29 S2 ; Clear any height map G29 S0 ; Probe the bed & save the height map M98 P"stowactuator.g" ; Stow the Z probe actuator back in the frame dock
I use the start g code section in my slicer to handle homing and loading the height map
Thanks.
Are you setting the Z=0 Datum in bed.g?
Frederick
-
This post is deleted! -
@arnold_r_clark said in Conditional G-Code assistance:
Yes
Thanks for the feedback.
One thing I forgot to mention, it may be of interest. You are invoking your homing files with M98 which usually works fine. Using G28 has one difference which can be important, it marks the specified axes as un-homed just before executing your homing files.
Frederick
-
This post is deleted!