Syringe Pumps / Depositing Viscous Materials

DocTrucker

...some of that pause is due to the hysteresis introduced by the slight shifting of the syringe in the holder, and in the part that holds the plunger handle.

DocTrucker

More testing. Two switches are wired up to the e0 and e1 inputs. The e0 switch calls trigger2.g and e1 is wired up as the limit for axis B. (Need to test whether you can drive to home switch on E axis)

This video shows the basic function. Empty switch is pressed which calls for a drive to home. The home limit is then triggered when the cylinder is full.

https://youtu.be/YiImdOBnOK8

The following video simulates what would happen if the axis were triggered in the middle of a move. You can clearly see the trigger is a lower priority than the G1 command. The G1 move is started, the cylinder move is started, the empty switch pressed and the G1 move completes before executing the trigger macro:

https://youtu.be/QrsB7TNTLZM

Can this be changed so that the trigger is a higher priority than G1?

If so is there a guide to how I could store the position of the axis before the home drive and then re-apply it after the home drive to save it doing some strange things? This may also be useful if swapping from one drive to the other as the active extruder.

If the trigger priority can't be changed it has obvious implications on the positioning of the switches, and forces a requirement to parse the g-code. There must be spare space after the switch trigger, and the gcode must be parse to ensure no extruder move is long enough to travel further than that distance.

Edit: Confirmed drive to limit does not behave the same on the extrusion axis as the other axis. There doesn't appear to be a H parameter that means the G1 will terminate on a specific input.

Phaedrux

There's no real way to interrupt a long G1 move at the moment. Breaking the single long move up into smaller shorter moves would allow an interrupt to get in between.

gaweyo

Could perhaps remap endstops instead of triggers?

DocTrucker

Currently working on using the trigger to signal the syringe is nearly empty and swapping the drives around with M584 between E and B so I can do a home drive in the B axis and carry on with the other axis as E, which can't do home drives.

Very nearly working as it should do - but obviously no parrallel motion without gcode parsing. To be fair since the syringes are fixed volume the switches could all be precoded in the build file.

Some oddness that smells like a bug but need to do some more work on that before raising it.

Edit:
Bug1: https://forum.duet3d.com/topic/22292/bug-rrf-3-3beta2-g92-b0-changes-e-axis-position
Bug2: https://forum.duet3d.com/topic/22295/bug-2-rrf-3-3beta2-axis-hanging-after-m584-re-assignemnt/10

DocTrucker

Some more tests on this system.

To be clear this is not the only approach for achieving the end goal of minimal down time for the syringe extruder. Hard coding the syringe retractions and changeovers into the build files would be a way of achieving this. This work as presented currently would also be better suited to a single syringe system as the change over has no benefit as presented. But it has help uncover a few peculiarities in the firmware, so not lost effort.

In the following tests there are two trigger routines associated with switches that will be used to tell the system a syringe is running low on material. These triggers switch the currently active syringe which is running low to the B axis and the other syringe back to the E axis from the B axis. After the drives are switched a drive to home is commanded on the B axis to refill the empty syringe.

The build file that is used is a simple octagon with 1mm drive on the syringes for each 1mm of head travel. This may not be a fit ratio for the final build but works well for tests. I've a python script that walks around the perimeter of the octagon and outputs G1 commands for every 1mm of head displacement.

Test 1 - Basic command line test with extruder drive switch over.

https://youtu.be/yIVtvmTzVWM

In this test the only commands I and sending from the console is G1 E25 F500 and I trigger the switches to simulate the syringe running empty and hitting its limit after drawing back to the home position.

Test 2 - Using the above functionality in a live print that only comprises of G1 moves of the X, Y, and E axis.

https://youtu.be/BpO3yiDUwMk

Here the challenges start to come to light.

A considerable delay between the trigger of the empty switch and the stopping of the system.
The full syringe begins to move before the empty syringe retracts. The retract command is called from the same trigger file as the swap of drives. Therefore the machine appears to see the trigger, change the drives, do a bit more from the main gcode
Retract executes after the full extruder has moved a bit.
A pause while the machine does nothing for a few seconds.
Normal service then resumes.

Test 3 - Basic command line test with extruder drive switch over, but with M300 peeps either side of the trigger files.

https://youtu.be/6EQhZ80h0D8

Running the "G1 E25 F500" command from the Duet Web Control again and manually triggering the limit switches to simulate the syringes running empty. In this test everything runs as expected.

Test 4 - Using the triggers from test 3 with beeps in a print as per test 2.

https://youtu.be/t0umi187DvQ

The addition of the M300 peeps exaggerate the interleaving of commands from the trigger file and the main gcode stream. A change over no looks like:

Empty switch triggered.
Machine carries on a bit
X/Y motion pauses.
Machine peeps
X/Y motion resumes with the other syringe driving.
X/Y motion pauses.
Empty syringe completes a home drive.
Machine sits idle for a few seconds
X/Y motion resumes and build process continues.

This looks exaggerated with the two syringes but the switch has probably saved the system from raising some strange errors. If I hadn't carried out the atomic command changing over the drives and was working on a single extruder what would have happened when the machine tried to carry on with a few more lines of gcode with no E drive assigned?

Test 5 - Adding pause commands to the triggers just inside the M300 commands that bookend the trigger files.

https://youtu.be/mh9XOSKL624

Yeah, so this highlighted the fact that the M25/M24 commands call the pause and resume macros. This would have been messy if I were working with fluid as on each pause the head jumps back to the middle before returning after. That said everything else happens as expected aside from the initial peep being missing completely, and the final peep occurring some moves after the resume as it both were outside of the M25/M24 commands.

I'll add the final macros at some point today. Changing between computers to do the tests so don't have them to hand right now.

DocTrucker

As promised here are the trigger files and other macros. More much neater looking videos to follow shortly including single syringe mode.

For Running Two Syringes

trigger2.g

M25
M300
M98 P"set_secondary_syringe.g"
G91
G1 H1 B-100 F400       ; Drive empty syringe to limit.
G90
M300
M24

trigger3.g

M25
M300
M98 P"set_primary_syringe.g"
G91
G1 H1 B-100 F400       ; Drive empty syringe to limit.
G90
M300
M24

set_primary_syringe.g

M584 E3 B4               ; Set primary syringe to active
M574 B1 S1 P"ystop"      ; Set limit switch
M84 E0                   ; A needed bodge!

set_secondary_syringe.g

M584 E4 B3               ; Swap drives
M574 B1 S1 P"xstop"      ; Set limit
M84 E0                   ; A needed bodge!

For Running One Syringe

trigger2.g

M25
M300
M98 P"set_secondary_syringe.g"
G91
G1 H1 B-100 F400       ; Drive empty syringe to limit.
G90
M98 P"set_primary_syringe.g"
M300
M24

DocTrucker

Moved the M300 peeps to within the M25 and M24, and modified the pause and resume system gcode files to stop the machine excessively moving and virtually dribbling all over the work place!

Dual Syringe Mode:

https://youtu.be/fHFTYhxONs4

And what makes more sense without any parallel motions or hard coded retracts single syringe motion:

https://youtu.be/Xv-oSVEzvxM

This system is now fit for trials, but the implementation is a bit messy with needing to disable the pause/resume macro functionality. A pause because a syringe has run low and a user pause are two different things, and I certainly wouldn't want additional XY movement for the former, but may for the latter.

I'll work at a slower pace at hard coding parallel syringe movements into the build file as a demonstrator of what would be ideal, but don't expect that video any time soon!

DocTrucker

@dc42 said in Syringe Pumps / Depositing Viscous Materials:

Let's suppose that we provide the following mechanisms:

A mechanism to assign each axis to one or other movement queue. So in M584 you would specify which movement queue any new axes you create would be assigned to. That assignment would probably be fixed.

A mechanism for wait for both movement queues to empty (probably M400 with an extra parameter).

Movement commands involving axes assigned to one movement queue would be permitted to happen concurrently with movement commands involving axes assigned to the other movement queue.

Would that be sufficient for your use case? If you think it would, can you write the macros that would be needed?

@dc42 I think I have demonstrated what you recommended now? I think All I would change is adding a gcode command to the beginning of the trigger files to wait for moves to complete on parallel gcode streams, and modify the home drive so that it occurred on a parallel stream rather than the main stream and that G1 home command didn't block until it completed?

DocTrucker

Not significant progress, but switches mounted and action proven without needing to manually trigger them. Got myself muddled with the rising and falling edge on the trigger and input inversion but other than that working smoothly.

https://youtu.be/b-8ElqegZcU

This will go quiet for a while while I look at a hard coded version where B retraction moves are in parallel to the other moves. Will look funky, but that puts more into the GCode file than I would like. Material levels etc are something that I would like macros on the machine to deal with and have the slicer oblivious.

Edit: Example macros removed as the triggers missbehaved when I removed M300. 3.3beta2 is being a nuisance with triggers.

dc42

@DocTrucker said in Syringe Pumps / Depositing Viscous Materials:

This system is now fit for trials, but the implementation is a bit messy with needing to disable the pause/resume macro functionality. A pause because a syringe has run low and a user pause are two different things, and I certainly wouldn't want additional XY movement for the former, but may for the latter.

I am wondering whether the filament change pause GCode M600 could be used instead of M25. It's intended to be used in the file being printed, so I would need to check whether it will work when used outside that file.

DocTrucker

@dc42 I'll have a look. The macros/triggers stipped working after I removed the M300 - which is odd. The triggers paused the machine properly rather than just functioning as an interlock to prevent other commands from the queue creeping in.

DocTrucker

@dc42 Just reading up on M600 now and it's better with being able to avoid the pause.g with an empty filament-change.g but not ideal;

You still resume with M24, and there is no way to dodge (or use an alternative) resume.g
It behaves differently in that firing M25 when idle will cause an error, firing M600 will put an idle machine into a paused state.

So, I'll test it for completeness (feedback soon) but it's not much use without being able to specify an alternative than resume.g.

DocTrucker

Messy, very messy on 3.3beta2. When using M600 the delay before refilling the syringe is longer (as expected from comments in the gcode wiki) and the resume.g gets interleaved into the main gcode stream after the resume happens, along with odd error messages about bad commands which indicate it has broken the reading of the gcode too.

The only way to get the above system to function well is with the contents of pause.g and resume.g commented out, and things are quicker with M25. I'd guess the length of the increase would likely be very build gcode dependent putting more emphasis on the parsing of gcode.

I think the bug report on needing to ensure trigger files (and any additional macros that they may call) are run in their entirety before running back to the build gcode needs to be investigated:

https://forum.duet3d.com/topic/22338/bug-ways-to-ensure-gcode-within-trigger-is-uninturupted