Jubilee - error then stops picking up tools

JoergS5

@BryanH I suspect the tool_lock macro line
G1 U360 F2000 H1
is invalid because in config. the M208 for U is
M208 U0:200

But I have no experience with tool changers, I may be wrong.

T3P3Tony

It looks like something (possibly in your tool change macros) is trying to move the print head outside of the limits defined by for the printer.

I am posting the relevant files from your github zip to make it easier to work out whats going on:

Console snip:

6/9/2020, 4:56:31 PM: Connected to jubilee.local
6/9/2020, 4:56:44 PM: M32 "0:/gcodes/Moai.gcode": File 0:/gcodes/Moai.gcode selected for printing
6/9/2020, 7:52:16 PM: : Error: G1/G2/G3: intermediate position outside machine limits
6/9/2020, 7:52:16 PM: : Error: G1/G2/G3: intermediate position outside machine limits
6/9/2020, 7:53:55 PM: : Error: G1/G2/G3: intermediate position outside machine limits
6/9/2020, 7:53:55 PM: : Error: G1/G2/G3: intermediate position outside machine limits
6/9/2020, 7:55:17 PM: : Error: G1/G2/G3: intermediate position outside machine limits
6/9/2020, 7:55:17 PM: : Error: G1/G2/G3: intermediate position outside machine limits
6/9/2020, 7:56:11 PM: : Warning: Firmware halted
6/9/2020, 7:56:11 PM: : Warning: Firmware reset imminent

Specifically it looks like the M208 command at the beginning of the TFreen.g and the equivalent at the end of tpost.g have been commented out:

;M208 X-11.5:311.5 Y-44:341		; Reclaim full travel region

This means that the subsequent commands to move to drop off the tool are outside of the allowed area.

I am not that familiar with jubilee but on the e3d toolchanger the area you want tool head moving around in with a tool loaded excludes the area where the tools are docked, hence using M208 to restrict and allow movement depending on whats happening.

as an aside rather than using M208 I use M564 S0 and M564 S1 to do the same thing. M208 is arguably safer because movement is still constrained within limits.

T3P3Tony

ahh good spot @JoergS5 that is also outside the limits.

JoergS5

@T3P3Tony so turning to 0 instead of turning to 360 may solve it.

BryanH

Thank you for the feedback, here’s some additional information.
Here is a photo of the three failures I’ve seen so far. The first two were with the M208s that are commented out in place. These limits are to keep the mounted tools from impacting the frame. The third attempt failed early.

Once the error occurs the job continues without picking up the tool. The tools continue to extrude filament and the carriage goes through the motions of each layer but just stops trying to rotate the lock.

I’ve set up a camera and am trying again while recording the activities.

JoergS5

This post is deleted!

JoergS5

This post is deleted!

JoergS5

@BryanH If you don't find the solution after the "video session", maybe you can show some images of your tool changer implementation, so we can discuss possible reasons for the problem.

T3P3Tony

@BryanH also maybe @poofjunior can offer some jubilee focused help with the lock/unlock macro.

BryanH

@T3P3Tony Thanks, @poofjunior and I were working on it last night before I posted here. he’s thinking there’s some firmware issue since I’m using the same macros that the rest of the community is using. The major difference is that I’m using a duet3(sbc).

JoergS5

@BryanH poofjuniors tool-lock in https://github.com/machineagency/jubilee/tree/master/software/duet_config_files/duet2/macros is different. He makes U200 and an additional Y0.5 movement. Maybe the y movement improves locking.

BryanH

@JoergS5 My hardware is a bit different - I've got a spring buffer on my tool posts that gets compressed during the tpost0.g code - it's something that @Miasmictruth and I were working on to see if we get a better lockup - as an aside the "TODO: read sensors" line in my macros/tool_lock.g is for the switch built into the front carriage plate that detects when all three balls of the Maxwell coupling are seated. You can see the io created in the config.g along with some general concepts related to a pause if the tool is disconnected during a print.

Just got away from work and running the job now.

JoergS5

This post is deleted!

JoergS5

@BryanH I wish you success in improving the tool changer. The whole topic is interesting and will bring forward 3d printing!

BryanH

@JoergS5 Any reason that the M208 U0:200 can't be commented out? The Remote Elastic Lock is a dual limit switch environment and all moves are seeking an endstop.

JoergS5

@BryanH I would set it to the min and max values youre using which is M208 0:360

BryanH

@JoergS5 Done - let's see what happens

BryanH

ok, it seems it's getting worse.

Just ran the job wilst recording - caught on tape was a failed lock -

The machine attempted to pick up T0, the lock didn't finish the rotation, I can't tell if the limit switch triggered or not. I tightened up the lock by hand and noted at that time there was no holding torque on the U stepper - it was off. It finished the layer and go to the point where the tool change was called (15:42:32)
The carriage moved T0 to the park position and placed the tool on the post then tried to run the tool_unlock.g macro, nothing happened. There was no movement of the lock. There were no reported errors at this point.
The carriage did not pull back to move to the T1 pickup position.
The error was reported twice at 15:43:01 and T1 became the active tool, T0 was still mounted on the carriage, then the carriage pulled back and continued the job as T1.
T1 operated as if it were mounted on the carriage, extruding with an active part fan.
At the end of the current layer when the next tool change was called the system attempted to part T0 in the T1 parking location - The E-stop did not immediately respond and I pulled the plug.

Is there a better logging option than the console?

Thanks,

H2B

Seems like the latest firmware has some runaway tool change code somewhere to me.. There doesn't seem to be anything wrong with the macros and the config file(s) for a Jubilee setup..

poofjunior

@BryanH said in Jubilee - error then stops picking up tools:

, the lock didn't finish the rota

Good eyes, folks! My first suggestion would be the same: ensure that any commands sent to the U axis are be no greater than the limits defined in M208. On the stock configs, axis limit for U is set to 200, and invoking tool_lock.g rotates the U axis with an endstop sensitive search up to U=200. (Units are degrees for U.) Since locking is torque-sensitive, the locking position is unknown and will vary slightly with cycles, but it will be in this range.

Side note: The latest revision of the Lock only will actually hard-stop around ~120 degrees on the U axis. This translates to a full 180 degrees on the carriage twist lock side, which is now hard-stopped from material on the carriage back plate. At this point, the internal locking spring will be fully, stretched, clicking the internal limit switch and halting the move.

It sounds like this fix didn't work so my next suspicion would be a disconnected/loose wire somewhere in the U axis wire harness.

To test loose wires, I'd remove the KK connector and hook up a multimeter to both loose leads. Then, with the U axis disengaged (M18 U), I'd rotate the lock by hand with the knob. Only in cases where the limit switches are clicked should you break the connection. If you break the connection when the switch is not clicked, there's a break in the wire harness.

Other Thoughts

Based on when your prints fail, this only happens "sometimes." In my mind, this makes me think:

something in the real world that's not repeatable (loose wires, or something about locking since the exact position can vary over cycles)
something about the firmware, which may have a memory leak or uncaught edge case.

References

Jubilee Wiring Diagram, upper left section for U axis wiring harness