I'm having some trouble with the "return to calling link node" feature. I have a flow that reads a file containing gcode line by line into a queue node, executes the gcode one line at a time up to a defined point (G4P0), then continues in the main flow until a call to resume passing gcode messages is reached. The trouble I am having is that since the messages are all passed into the queue node from the initial link call, they all contain a LinkSource that points them back to the original Link Call node and not the node that actually made the most recent call.
I could get around this by breaking up the gcode file into individual files and passing them separately, but for this project it will be nice to be able to see/edit the gcode in one file. Is there a workaround for this? I'm relatively new to node-red so it's very possible I'm missing something obvious.
I can't follow exactly what you are doing, but you cannot split the message inside the link call flow. There must be exactly one link return for each link call. I suggest that you do the split in the main flow.
In fact you might like to consider using the flow posted here for the queueing. Split the file and feed the lines into the the queue. Replace the 'functions to be performed' function with your test to see if you have got to the GP40 instruction, and if so then take whatever action you need before triggering the flush to release the next line.
Wow, I didn't realize the delay node could work like that. Again, I'm still new to this! I'll likely implement this instead of the "simple queue" node as it seems preferable to use built in nodes when possible.
It's understandable that it's hard to follow, I should have done a better job explaining the overall picture.
I'm building what is essentially a CNC positioner that does some non-gcode actions at certain points (temperature controls, ramping and switching of a power supply, etc). The main flow needs to know that the CNC has reached where it is supposed to be before starting the non-gcode tasks. Because it's a relatively large (~2m x 2m x 1m) slow moving gantry it takes a while to physically complete a line of gcode. For the CNC part I'm using a GRBL controller that returns an "ok" message after each line of gcode is parsed, which is usually long before it has physically reached that point. This is the reason for the G4P0 commands as the controller waits until a dwell command has been completed before returning an "ok" message. There are likely other ways to achieve this, but this seemed like a somewhat logical/easy to implement way to do it.
I agree that it would make more sense to split in the main call. For a number of reasons it seems like the better logic/functionality.
I would like to keep the main gcode file as a single file but perhaps there is a way using the read/write nodes to split the file at defined points (G4P0 in this case). I will look into that, but if you have any suggestions or tips for such a split I'm certainly open to them.
That makes sense. Basically separate the queue/gate operation from the gcode parsing subflow. I'll have to play around with that later, but I think it should work. Thank you for the follow up suggestion.
