@t3p3tony Just updated the firmware and I can confirm that the MAC is correct. Thanks
Posts made by sergio
-
RE: M540 and MAC address problems on Duet 3
-
RE: M540 and MAC address problems on Duet 3
@dc42
If you are looking into that code. The hex format also doesn't seem to work anymore, not sure if you are removing backwards compatibility, but if that is the case a note would be good on the M540 description.M540 P0xB1:0xEF:0xD0:0xAD:0xDD:0xFD ; This format doesn't work anymore M540 PB1:EF:D0:AD:DD:FD
Thanks a lot for the fast response.
Sergio -
RE: M540 and MAC address problems on Duet 3
@t3p3tony
3.2 doesn't resolve the issue. -
RE: M540 and MAC address problems on Duet 3
None of my Duet3 change MAC address.
Here is another example:; CONFIGURACION GENERAL G90 ; Establecer coordenadas absolutas M83 ; Establecer movimientos del motor relativos M550 P"AM_204" ; Nombre de la máquina (Afecta a la interfaz, no se si también a su identidad en la red) ;Configuración de RED ; M540 P0xB1:0xEF:0xD0:0xAD:0xDD:0xFD ; This format doesn't work anymore M540 PB1:EF:D0:AD:DD:FD M552 P192.168.102.104 ; Activar comunicación por red, con IP local 1.130 M554 P192.168.0.1 ; Puerta de enlac M553 P255.255.0.0 ; Mascara de red M586 P0 S1 ; Activa protocolo HTTP M586 P1 S1 ; Desactiva protocolo FTP M586 P2 S0 ; Desactiva TELNET M552 S1
Reported by the duet:
M540 MAC: b1:ef:d0:ad:dd:fd
Arping returns [BE:62:39:3B:53:31]
$ arping -c 1000 192.168.102.104 -I ens3 ARPING 192.168.102.104 from 192.168.102.1 ens3 Unicast reply from 192.168.102.104 [BE:62:39:3B:53:31] 0.802ms
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.3beta2 running on Duet 3 MB6HC v1.01 or later (standalone mode) Board ID: 08DJM-956L2-G43S8-6J1D2-3S86S-1A32D Used output buffers: 1 of 40 (13 max) === RTOS === Static ram: 148476 Dynamic ram: 90516 of which 548 recycled Never used RAM 114652, free system stack 154 words Tasks: NETWORK(ready,234) ETHERNET(notifyWait,120) HEAT(delaying,278) CanReceiv(notifyWait,945) CanSender(notifyWait,360) CanClock(delaying,335) TMC(notifyWait,58) MAIN(running,1113) IDLE(ready,19) Owned mutexes: === Platform === Last reset 16:21:16 ago, cause: software Last software reset time unknown, reason: User, GCodes spinning, available RAM 114652, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Aux1 errors 0,0,0 MCU temperature: min 48.8, current 51.0, max 54.5 Supply voltage: min 23.9, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.1, max 12.2, under voltage events: 0 Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Driver 0: position 47314, standstill, reads 41408, writes 19 timeouts 0, SG min/max 0/172 Driver 1: position 47293, standstill, reads 41409, writes 19 timeouts 0, SG min/max 0/171 Driver 2: position 47328, standstill, reads 41409, writes 19 timeouts 0, SG min/max 0/160 Driver 3: position 0, standstill, reads 41414, writes 14 timeouts 0, SG min/max 0/0 Driver 4: position 0, standstill, reads 41414, writes 14 timeouts 0, SG min/max 0/0 Driver 5: position 0, standstill, reads 41417, writes 11 timeouts 0, SG min/max 0/0 Date/time: 2021-10-06 11:51:00 Slowest loop: 12.65ms; fastest: 0.06ms === Storage === Free file entries: 10 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 4.4ms, write time 0.0ms, max retries 0 === Move === DMs created 125, maxWait 51ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 5, completed moves 5, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === CAN === Messages queued 529894, send timeouts 529891, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 49 (min 49) Last cancelled message type 30 dest 127 === Network === Slowest loop: 12.65ms; fastest: 0.02ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 2 of 8 - Ethernet - State: active Error counts: 0 0 1 0 0 Socket states: 5 2 2 2 2 2 0 0
Best.
Sergio -
RE: M540 and MAC address problems on Duet 3
@dc42
Sorry, I was asking someone to turn off that machine in that factory. I cannot access both remotely through the VPN so I needed remote hands to help me.m122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.3RC1 (2021-05-01 09:12:50) running on Duet 3 MB6HC v1.01 or later (standalone mode) Board ID: 08DJM-956L2-G43S8-6J9D0-3SJ6Q-9A0YG Used output buffers: 3 of 40 (15 max) === RTOS === Static ram: 150680 Dynamic ram: 90564 of which 516 recycled Never used RAM 109576, free system stack 154 words Tasks: NETWORK(ready,31.5%,226) ETHERNET(notifyWait,1.7%,112) HEAT(delaying,0.2%,295) Move(notifyWait,0.4%,268) CanReceiv(notifyWait,0.0%,945) CanSender(notifyWait,0.0%,359) CanClock(delaying,0.1%,335) TMC(notifyWait,96.6%,93) MAIN(running,93.5%,1114) IDLE(ready,0.0%,29), total 224.0% Owned mutexes: === Platform === Last reset 17:11:23 ago, cause: software Last software reset time unknown, reason: User, GCodes spinning, available RAM 109576, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Aux1 errors 0,0,0 Step timer max interval 224 MCU temperature: min 39.2, current 41.6, max 44.2 Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.1, max 12.2, under voltage events: 0 Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/8/0, gc cycles 0 Driver 0: position 46840, standstill, reads 18330, writes 19 timeouts 0, SG min/max 0/194 Driver 1: position 46831, standstill, reads 18330, writes 19 timeouts 0, SG min/max 0/174 Driver 2: position 46839, standstill, reads 18330, writes 19 timeouts 0, SG min/max 0/190 Driver 3: position 0, standstill, reads 18336, writes 14 timeouts 0, SG min/max 0/0 Driver 4: position 0, standstill, reads 18336, writes 14 timeouts 0, SG min/max 0/0 Driver 5: position 0, standstill, reads 18339, writes 11 timeouts 0, SG min/max 0/0 Date/time: 2021-10-06 11:47:54 Slowest loop: 6.42ms; fastest: 0.05ms === Storage === Free file entries: 10 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 2.6ms, write time 0.0ms, max retries 0 === Move === DMs created 125, maxWait 146ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 5, completed moves 5, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === CAN === Messages queued 556955, send timeouts 556952, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 49 (min 49) Last cancelled message type 30 dest 127 === Network === Slowest loop: 6.08ms; fastest: 0.02ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 2 of 8 - Ethernet - State: active Error counts: 0 0 1 0 0 Socket states: 5 5 2 2 2 2 0 0
-
RE: M540 and MAC address problems on Duet 3
@t3p3tony can confirm on his test base, I guess it could be a firmware issue?
I will try to go down to 3.2 for the machine that is in conflict, since it is not very happy in the network.M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.4.0beta4 (2021-09-27 11:31:18) running on Duet 3 MB6HC v1.01 or later (standalone mode) Board ID: 08DJM-956L2-G43S8-6J9D0-3SJ6L-9A0GG Used output buffers: 1 of 40 (33 max) === RTOS === Static ram: 151080 Dynamic ram: 93860 of which 0 recycled Never used RAM 105732, free system stack 206 words Tasks: NETWORK(ready,29.8%,225) ETHERNET(notifyWait,0.1%,170) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.0%,351) CanReceiv(notifyWait,0.0%,906) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,339) TMC(notifyWait,8.2%,92) MAIN(running,61.9%,1113) IDLE(ready,0.0%,30), total 100.0% Owned mutexes: === Platform === Last reset 00:59:19 ago, cause: software Last software reset at 2021-10-06 11:29, reason: User, GCodes spinning, available RAM 105732, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Step timer max interval 133 MCU temperature: min 32.8, current 34.1, max 34.2 Supply voltage: min 27.6, current 27.9, max 28.1, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.1, max 12.2, under voltage events: 0 Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Driver 0: pos 0, standstill, SG min/max 0/0, reads 54487, writes 17 timeouts 0 Driver 1: pos 0, standstill, SG min/max 0/0, reads 54487, writes 17 timeouts 0 Driver 2: pos 0, standstill, SG min/max 0/0, reads 54487, writes 17 timeouts 0 Driver 3: pos 0, standstill, SG min/max 0/0, reads 54487, writes 17 timeouts 0 Driver 4: pos 0, standstill, SG min/max 0/0, reads 54494, writes 11 timeouts 0 Driver 5: pos 0, standstill, SG min/max 0/0, reads 54488, writes 17 timeouts 0 Date/time: 2021-10-06 12:28:42 Slowest loop: 6.31ms; fastest: 0.05ms === Storage === Free file entries: 10 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 2.6ms, write time 0.0ms, max retries 0 === Move === DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 2 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty === CAN === Messages queued 32045, received 13, lost 0, longest wait 1ms for reply type 6018, peak Tx sync delay 6, free buffers 49 (min 48), ts 17796/17795/0 Tx timeouts 0,0,0,0,0,0 === Network === Slowest loop: 10.23ms; fastest: 0.02ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 4 of 8 - Ethernet - State: active Error counts: 0 0 1 0 0 Socket states: 5 5 2 2 2 2 0 0
-
RE: M540 and MAC address problems on Duet 3
Will try 3.3 stable, and it is stand alone.
We use it pretty much as a duet 2. -
RE: M540 and MAC address problems on Duet 3
More tests, updated firmware to 3.4 Beta 4
Board: Duet 3 MB6HC (MB6HC)
Firmware: RepRapFirmware for Duet 3 MB6HC 3.4.0beta4 (2021-09-27)Turned off network before changing MAC
M552 S0
M540 P00:AD:BE:EF:CA:00
M552 P192.168.102.101
M554 P192.168.0.1
M553 P255.255.0.0
M552 S1Stills gives:
Unicast reply from 192.168.101.121 [BE:62:38:3A:53:37] 0.994msSecond duet in conflict:
Unicast reply from 192.168.102.105 [BE:62:38:3A:53:37] 1.384msM540 gcode returns the right MAC, but it doesn't seem to be propagated to layer 2.
-
M540 and MAC address problems on Duet 3
Hi,
I have an issue with Duet 3 Ethernet. I have two machines that report the same address BE:62:38:3A:53:37 and i get a conflict on my network.
I tried different formats:
M540 PDE:AD:BE:EF:CA:FE
M540 P0xDE:0xAD:0xBE:0xEF:0xCA:0xFEI test using arping and I can see the MAC addresses changing on the Duet 2 - Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.2 (2021-01-05)
But Board: Duet 3 MB6HC (MB6HC)
Firmware: RepRapFirmware for Duet 3 MB6HC 3.3RC1 (2021-05-01)
doesn't seem to be changing with the same config/code.M540 reports correctly the new MAC address specified on the M540, but arping reports the original interface.
It doesn’t seem to change. I have around 20 Duet 2 printers that can change the MAC correctly in but firmware 3.3 doesn't seem to work.G90
M83
M550 P"AM_NAME"
M540 PDE:AD:BE:EF:CA:FE
M552 P192.168.102.101
M554 P192.168.0.1
M553 P255.255.0.0
M586 P0 S1
M586 P1 S1
M586 P2 S1
M552 S1This is my config start setup, any recommendation?
Best -
RE: RR_reply and echo
Here you can find my tests to talk to the Duet using Python 3 and a Duet 2 running version 3.11 and a Duet 3.
https://github.com/triditive/duet_test/blob/master/duet_python_test.py -
RR_reply and echo
When I run gcodes through the API, they go into the buffer, and then they come back in the execution order (I think), but I don't really have any way to know which call generated which response.
Like if I am checking for a command to finish or trigger some event somewhere in a pin, the order of the events is important.
I was trying to use M117 for this since, in theory, it returns back your message as echo if there is not an LCD.
Then I discovered, that it indeed it generates a rr_reply but there is no content on it, the UI is getting the response through a weird
rr_model?flags=d99fn
rr_model?key=state&flags=d99vnI don't think I fully understand the architecture of the message system, or I am trying to ask too much from it. Is there any extra documentation I could read?
I moved the automation into a different hardware interface, so the duet 3 will not delete the buffer, but the UI also echos every command I run there, killing the UI with messages.
For me, I just need M117 to reply back on rr_reply or having an echo message that gets into the pipeline and I will put a timestamp/mark there so I can parse the responses in an event queue, instead of a regex expression that is trying to figure out how many times I've seen this message.
The current communication system is not very ideal for having machine 2 machine communication at the moment.
Are there any plans for having a different API?
-
RE: rr_reply and http interfaces
@chrishamm said in rr_reply and http interfaces:
We may consider adding a new HTTP header that holds the session number for RRF 3.02 but I cannot estimate when that will be implemented.
That would be very useful.
-
RE: rr_reply and http interfaces
The UI has the same IP as the machine running the commands since it has a large touch screen with our HMI and the Webcontrol, that is why i didn't realize about the IP sessions, I normally VNC into that machine for testing too.
I guess I can have a second network interface on the machine and use that to query for the reply, not ideal but it would work.
In terms of commands and automatism. I do a full calibration after each print, so I run G32 and G29 after a platform change and I check that the calibration is in range after it finished calibrating. Sometimes if a platform failed to load, the calibration results are way out of range, so I have to query for the height of the printer and other parameters that came from the calibration to check if they are in range.
But I also want to run the rest of the system, I have PLCs and several systems with a Marlin which run commands, like moving the platforms around, turning conveyor belts, setting chamber temperature, lights on, sensors, turn on air filters, etc.
In the Marlin hardware, I read directly pins and set pins up so I can move something until it hits an endstop. I modified the marlin to get the number of steps that took to hit that endstop so I can do things like calculating the amount of displacement and get extra information for our calculations.
I also normally poll for endstops, to check their state. If an operator opens a door, I want to pause that part of the machine and not only pause the duet. As you see, I kind of use the marlin hardware as a general-purpose state machine/controller.
I guess I am trying to find a way of using the duet the same way. Since in Marlin, I just run the command through USB and wait until the end result I have full control of what is doing, and it works in parallel with the Duet as an industrial controller.
My doubt at the moment is if I can use the Duet to run things in parallel while it is printing, or maybe I will have to have a dedicated duet for the automatism and have a bus.
I guess my architecture is a bit complicated at the moment and I am trying to simplify it.
Any suggestions?
-
rr_reply and http interfaces
I've been struggling a little bit to fully integrate the duet and replace some of our extra hardware to move all our external functionality to the Duet.
This topic is related to this:
https://forum.duet3d.com/topic/5317/api-duet-responses-to-gcode-sentMy main issue is with the transactional mechanism of the webserver to reply to a GCODE command.
I am currently running our server & automatisms in parallel with the DUET web UI. An operator will have the DUET web UI open and maybe someone in a tablet too monitoring some temperature or something simultaneously.
Every command I issue from my system has a chance of getting their reply hijacked by one of the external UIs at /rr_reply, therefore I have to query, check if there is a response, query again after 0.5s if I don't see any response... That doesn't seem very reliable in the long term.
Given the nature of the system, I think a simple queue of transactions that you can query with an ID would solve the issue and make the system more robust in the long term.
A bit more advanced, I would send a GCODE command request and I would get a timestamp from the webserver that I can use to query back to see if there is a response for me. That response queue could just be stored in a simple FIFO, only a few lines long. I guess that would force the pipeline to carry the transaction ID, kind of like a regular execution payload in a kernel and without looking deep into the architecture I cannot evaluate the amount of work required.
I haven't been looking into the code yet to build a PR, only a little bit into the webserver to see how it would fit. Is this something that would be accepted?
Best,
Sergio
https://github.com/sergioamr/