Firmware 2.03beta2 available

deckingman

@dc42 said in Firmware 2.03beta2 available:

Here's an example of swapping the X and Y endstop inputs:

M574 X1 S1 C1 ; X endstop is connected to input 1 which is labelled Y
M574 Y1 S1 C0 ; Y endstop is connected to input 0 which is labelled X

Thanks. One more question. I assume that if I go into the machine properties section of DWC, then in your example above, if I trigger the endstop for the X axis I would expect the Y axis switch to trigger. Correct? Or is the Machine Properties section of DWC clever enough to know that the switches have been re-mapped?

dc42

The endstop states are passed to DWC after remapping, so DWC should read correctly.

Edgars Batna

Just did a quick print on my CoreXY. No obvious issues.

dragonn

CoreXY - everything seems to working fine.

deckingman

@dc42 Sorry to be a pain but for the purpose of re-mapping end stops, can I just ask if the following input assignments vs labels is correct?

On the Duet Ethernet......

Label "X" is input 0
Label "Y" is input 1
Label "Z" is input 2
Label "E0" is input 3
Label "E1" is input 4

On the Duex 5.........

Labels E2 to E6 are respectively inputs 5 to 9.

Is that correct?

dc42

@deckingman said in Firmware 2.03beta2 available:

@dc42 Sorry to be a pain but for the purpose of re-mapping end stops, can I just ask if the following input assignments vs labels is correct?

On the Duet Ethernet......

Label "X" is input 0
Label "Y" is input 1
Label "Z" is input 2
Label "E0" is input 3
Label "E1" is input 4

On the Duex 5.........

Labels E2 to E6 are respectively inputs 5 to 9.

Is that correct?

Correct. Also inputs 10 and 11 are the two on the CONN_LCD connector. It's the same numbering as in the M591 command.

deckingman

@dc42 Thanks. - I don't have any filament sensors so I've never looked at M591.

May I suggest that this input numbering vs label be included in the Wiki somewhere. Either in the section entitled "connecting end stop switches" or in the section dealing with M574. I don't think I trust myself to edit the Wiki personally but I'll have a go if you like.

dc42

Next time we revise the Duet we will number the endstop inputs and motor outputs, instead of giving them axis and extruder labels.

deckingman

@dc42 said in Firmware 2.03beta2 available:

Next time we revise the Duet we will number the endstop inputs and motor outputs, instead of giving them axis and extruder labels.

Yes I believe you've said that before - makes perfect sense. Hindsight is always 20:20

deckingman

Just want to report that this (firmware 2.03 beta2) is all working well for me. CoreXYUV is all doing what it should do. Also I have been able to get homing working on my 3rd gantry by temporarily assigning both drives and end stops to X and Y axes.

The homing file is a bit complicated because basically I'm homing 7 axes - initially a course home, followed by a finer home at slower speed for each axis. Then re-mapping all drives and end stops so that for printing, it becomes a 3 axis machine.

Anyway, big thanks to David.

AndreS

@deckingman said in Firmware 2.03beta2 available:

May I suggest that this input numbering vs label be included in the Wiki somewhere. Either in the section entitled "connecting end stop switches" or in the section dealing with M574. I don't think I trust myself to edit the Wiki personally but I'll have a go if you like.

I have put it in with M574.

deckingman

@andres said in Firmware 2.03beta2 available:

@deckingman said in Firmware 2.03beta2 available:

May I suggest that this input numbering vs label be included in the Wiki somewhere. Either in the section entitled "connecting end stop switches" or in the section dealing with M574. I don't think I trust myself to edit the Wiki personally but I'll have a go if you like.

I have put it in with M574.

Thanks - I'm sure others will appreciate that information.

wilriker

@andres said in Firmware 2.03beta2 available:

I have put it in with M574.

And for the sake of completeness I also added a table to Connecting endstop switches in the wiki.

deckingman

@wilriker Very nice

dc42

I've put an update to firmware 2.03beta2 for the Duet WiFi/Ethernet and Maestro at https://www.dropbox.com/sh/mk3jlsoi6gyxd8q/AABbEvX2qb19McbRe6UvRmI9a?dl=0. Changes in this version:

New M505 command to support multiple configurations more easily (see separate thread)
Bug fix for file selection on 12864 displays on the Maestro
Bug fix for CNC and laser machines (was complaining about attempts to move outside the allowed limits during homing)
Increase max numbers of extruders and heaters per tool to 8 on the Duet WiFi/Ethernet
Babystepping command (M290) now works on any axis, however at present only Z babystepping can jump moves in the movement queue

NicoLab28

there have been changes for the M291 triggers / messages in tool change macros?

dc42

@nicolab28 said in Firmware 2.03beta2 available:

there have been changes for the M291 triggers / messages in tool change macros?

M291 sets baby stepping, it has nothing to do with triggers.

NicoLab28

M290 is for baby stepping.
I'm talking about blocking tool change macro with a message using trigger and M582.
When we put M291 command in trigger#.g

https://forum.duet3d.com/topic/8381/m291-s2-does-not-block-macro-execution

dc42

My mistake, M291 is for displaying messages and optionally waiting for a response.

What are you trying to use M291 in a trigger to do?

NicoLab28

Interrupt the tool change macro, to make a manual intervention, and resume.

In tfree.g tpre.g or tpost.g, if we make an M582, then an M291 in trigger # .g the message arrives after the end of the tool change.

As a result, the problem could not be resolved