Posts made by semi55

@dc42 Have you already had a chance to look into this topic? Please let me know if you need any additional information; I’ll be happy to provide any necessary feedback.

Thank you very much!

@droftarts ok thank you very much!

@droftarts Hi Ian,
Have you had a chance to have a chat with @dc42 yet?

@droftarts I understand that mapping the axis is nesscecary for keeping the gcode simple. But with this odd behaviour it is not usable for controlling the axis manually via the jogging buttons as described above when implemented in the config.g in combination with the described problems. That is why I have implemented this before a print starts in a macro so that I can control both axis with the applied limits in "manual mode" without crashing the tools. Applying these limits is just a workaround.

There might be a couple of misunderstandings because I initially thought when the U axis isn't hidden, jogging X when tool 1 is selected moves the X axis and jogging U moves the U axis, which is apparently not the case when U is mapped to X. But having two jogging controls which can produce unpredictable movements when mixed up seems like an unsafe choice which makes this option not feasible.

Hiding the U axis makes the printer dysfunctional when tool 1 is selected, that is why I implemented the described workaround. I would much rather use the hiding feature, that would also make the workaround redundant.

Regarding updating the position when T1 is moved via an X command with M400 would only be possible when this is done automatically or otherwise the users might forget that and get unexpected behavior.

Here is my M115 output:

FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6XD FIRMWARE_VERSION: 3.5.2 ELECTRONICS: Duet 3 MB6XD v1.01 or later FIRMWARE_DATE: 2024-06-11 17:13:17

The X and U axis are conntected to 1HCL boards (I have 4 in total).

@droftarts I figured out a way easier and cleaner solution.
In "idle" mode (not printing), when for instance tool 0 is selected, I limit the minimum and maximum travel of the second axis (U) to a couple of mm's around the parking position. I do the same when tool 1 is selected but then limit the X axis in the same manner.
I do have to alter a couple of homing files and some other macros, but this works exceptionally well. I can only fully move one axis at a time when selecting tool 0/1.

Before printing, I change the limits to the original values and everything is back to normal.
After printing, I got back to the limits as described above (this gets handled through custom macros and a bit of conditional Gcode).

During this process, I stumbled on something that seems like a bug or maybe some missing information. In the IDEX configuration wiki, it is stated that when a tool uses the U carriage for X movement it needs an X3 parameter in the M563 command.
I did implement this in the config.g (because this printer is only designed to use one tool at any given time) and now I realized that this should be rather implemented in the slicer Gcode or a custom macro which gets executed before each print.
Implementing this in the config leads to really strange behavior. When tool 1 is selected, no matter if I move X or U, it always moves the U axis. If I move "X" first, the U-axis moves the asked amount. If I then move the "U" axis, it firstly goes back to the position it was before the X move and then moves the requested amount.

So should a IDEX machine be setup like this (basic example):

M563 P0 D0 H1 F1 ; tool 0 uses extruder 0 and heater 1 and fan 1
G10 P0 X0 Y0 Z0 S0 R0 ; set tool 0 offsets and temperatures
M563 P1 D1 H2 F2 ; tool 1 uses extruder 1 and heater 2 and fan 2
G10 P1 X0 Y0 Z0 S0 R0 ; set tool 1 offsets and temperatures

and mapping the second axis to different conditions ( one tool, mirror mode...) should be done in the slicer?

If this is the case, could this information be added to the wiki page (if you also think this is usefull)?

@droftarts but that would mean that when tool 1 is selected and U is visible, X would also be visible and one could manually jog X or U until the tools crash into each other? That would also pose a potential crash with the bed as the tools can have different heights.

My aim is it to only be able to move one (X) axis manually at a time:

If tool 0 is selected: only the X-axis can be moved via the jogging buttons.

If tool 1 is selected: only the U-axis can be moved via the jogging buttons.

The machine will be used in a professional environment with different users and I want to avoid that one could crash the tools into each other or into the bed as they can have different Z-heights.
The users will not use Gcode for manual movement but definitely the jogging buttons on the DWC.

Would it be possible to hide the X-axis when tool 1 is selected?

If not, would it be possible to write a plugin that controls every incoming G1 command while not printing and does something with that?

@droftarts Hi Ian,

thank you for your swift reply.
That seems doable but if I understand this correctly, I would not be able to move the U-axis when tool 1 is selected and the U-axis is hidden with M584 P3? So I have to display U and X when T1 is selected because I have to unhide all axis?
That would unfortunately defeat the purpose of the safety feature as the user should only be able to move one tool at a time and this would only be available on tool 0 when hiding the U-axis if I understand that correctly.

Can this be achived through changing the axis mapping when swapping tools i.e. mapping U as X and X as U when switching to tool 1?

Like this (swapping X and U):

When tool 0 is active:

M584 X1.0 Y0.0:0.1 Z0.2:0.3:0.5:0.4 U3.0 P3

When tool 1 is active:

M584 X3.0 Y0.0:0.1 Z0.2:0.3:0.5:0.4 U1.0 P3

I have a gut feeling that this might be not the best solution as I fear that this will interfere with offsets and other stuff
This would also require me to switch tools when homing X and U is requested for instance.
Though this would only need to be done when no print job is running so I could basically use the standard setup while printing and only swap the axis mapping when controlling the machine manually.....

@droftarts Hi Ian,

I've implemented your suggested solution, but unfortunately it does not work as intended or I misunderstood the way it should work. It apparantly seems that it disables the selected axis and not hide it.
When I put the following code in my config.g, I am not able to home the U-axis when tool 0/1 is selected.

M584 X1.0 Y0.0:0.1 Z0.2:0.3:0.5:0.4 U3.0 P3                            ; set axis mapping, hide U-axis (P3)

I thought that this only hides the jogging buttons and I can still move the U-axis through G-code if needed.
When I then switch to tool 1, I am not able to move the U- or X-axis. Only X, Y and Z are displayed. Moving X results in no movement of the axis but the position in the DWC changes which is also quite strange. Trying to use M584 P0 thinking that this hides the X Axis and shows the U-axis again only results in an error (invalid number of visible axis).

Do I need to set a new axis mapping every time I switch the tools (which would probably mess up my Z-offsets)?
Am I missing something else?
Do I have to run the tool changes script when homing all axis to be able to home X and U?

Thanks in advance.

@droftarts that is true and I also have it setup this way. But with the standard configuration without the P3 addition one could move the tools into one of those overlapping areas manually and that would result in a crash. But that is fixed with hiding the second axis and setting up the tool change scripts accordingly as you suggested. I was just missing this last piece of information.

Thank you very much

@droftarts Hiding the additional axis sounds like exactly what I need.
Thank you very much for this clean solution, I am going to implement this next week as I have no access to the printer right now.
That would also solve the problem with the difference in Z height as each tool gets probed when the axis are homes and then switching the tools also takes the offset into account, awesome!!

Would it be possible to add this information (hiding one axis in the DWC) to the wiki page of the IDEX setup? I think that this is generally a quite usefull information.

@dc42 Would it be possible to use motor stall detection (M915) if nothing else is possible?
Both axis run on a 1HCL expansion board with TMC2160A controlling a Nema23 3Nm stepper motor.

That wouldn't be the most cleanest solution but better than the toolheads crashing into each other and damaging the machine in the process.

EDIT: just read some Wiki pages and saw that stall detection on CAN-FD expansion boards isn't yet supported and will probably supported with the release of 3.6.
Are there any plans on this yet?

@dc42 Is M597 intend to work during a print job only or is this also checked when moving the axis manually?

@semi55 what is even more odd is that the calculated keepout zone is only applied to the minimum side, the maximum side is always -0.0 .
I have moved the U axis to U0 to demonstrate this behavior as seen in the image below:

@dc42 Thanks for your reply.
I have added this to deamon.g in a separate macro called crashdetection.g and it kinda works but not 100%:

var crashXmin = move.axes[3].machinePosition - 50
var crashXmax = move.axes[3].machinePosition + 50
var crashUmin = move.axes[0].machinePosition - 50
var crashUmax = move.axes[0].machinePosition + 50


M599 X{var.crashXmin}:{var.crashXmax} U{var.crashUmin}:{var.crashUmax}

This is what gets executed in deamon.g (this will be eventually only executed outside of a printing job)

    M98 P"crashdetection.g"
    G4 S1

This applies the keepout zone but only for the U axis and only if the X axis stays under X50.

Any advice?

Hi there,

I have build a quite large IDEX machine with relative strong motors and I would like to implement some software safety features. Would it be possible (through deamon.g?) to limit the axis movement when controlled manually in "busy" mode?

A short example:
Lets say I have every axis homed and the X-axis is at X0 and the U-axis is at U200. Now when commanding the X-axis to X200 manually with Gcode or the jogging buttons on the web interface, it would crash into the U-axis.

Would it be possible to implement conditional Gcode to prevent that from happening if the machine is not in printing state?

Same goes for the Z-height when using tool 0 or tool 1 as they can have different lengths. Would it be possible when manually moving the X-axis that movement would only be possible when the U-axis is at a certain safe location?

@droftarts Thank you very much Ian for your elaborate answer. That solved it!
I've chosen the easy route and used I_O4 and I_O7 and they are working perfectly now.

Hello,

I want to connect two Tower Pro MG996R servos to the 6XD mainboard via output 4 & 5. They are powered through a separate 5V PSU which shares the GND with the main PSU.

Following the wiki guide Connecting hobby servos and DC motors and setting things to:

M950 S3 C"out4" ; Servo left, servo mode
M280 P3 S0 
M950 S4 C"out5" ; Servo right, servo mode
M280 P4 S0 

This does nothing and the servos don't move at all.

I have also tried connecting one to out6 which provides a 5V PWM but that doesn't help.
Any help will be highly appreciated.

@jay_s_uk That worked perfectly, thank you very much!

@jay_s_uk I have updated the firmware of all four boards with M997 B# but i am getting the same error message unfortunately.
The current firmware version of the 1HCL boards is version 3.4.4

@jay_s_uk Thank you very much for this incredibly swift reply. I will give this a try and come back with the result!