@gloomyandy sorry, didn't mean to complicate things. I appreciate the effort. Please let me apologize ahead of time for the rant...

Ever since the last update, things have been wonky and it's hard to tell what symptom is distinct in cause from other symptoms.

The behavior isn't consistent either. I'm seeing the pop stack aux() error now on the PanelDue due to some command in the DWC, as opposed to when I tap a button on the PD. I'll be working from DWC for a while, then walk over to the machine and see it on the screen.

I can't come up with what triggers it. That's the problem. There are so many variables. And because it's a tool changer with sensor and button on the tool head itself, there is A LOT of logic spread all throughout to avoid crashes, clean the tools, temperature sensitive operations, eject, load.

I honestly don't have enough time to go through so many variables. I built a "platform" that is orchestrated well. One update later and I'm down 4 bent Obxidian revo nozzles $50/each, 3 PEI magnetic sheets gouged to hell, a dozen Z-axis lead screws bowed out from crashes, and the list just keeps growing.

Nothing in the changelog impacts any of my configuration.

These things are just supposed to work and supposedly are "validated" that the logic works.

I honestly expect somebody else to figure it out at this point, nobody specific, but Duet.

@dc42 I see! That fixed all of my issues, thank you.

@droftarts :
I see this is happening only with 1/2 versions of cura generated Gcode. If I use latest Cura version gcode, I don't see this problem much. However, I will see if stopping the log , helps anyway.
Also, I do see that this problem does not appear in previous versions of RRF. May be something is changed w.r.t certain gcode interpretation.

@Phaedrux : Please mark this as solved.

@ziggymanpopo M303 see: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Heaters_tuning

Don't use bang bang. Treat it has any other controlled heater and do a PID tuning on it for stable control. Bang bang is likely to cause Z banding.

The SSR will have a rated input voltage for the signal side. As long as your VIN is in range, it should be able to switch it without issue.

See here for more info: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Heaters_bed

@Tinchus said in reconection to wifi after disconnect:

Is there a way to make duet reconnect again to the network / retry the connection without rebooting it?

see M587.1: Start network scan

@droftarts No problem, thank you!

@droftarts Many Thanks Ian the connection was on the far left of the board out of sight. I am now connected and just chewed up my first piece of wood.

@oliof Thanks, I just realized that my original Duet is the Maestro. The Ender has the Ethernet board. The Maestro is in a drawer. Actually, I would REALLY prefer to go the CAN bus route now that I think about it. I guess my Maestro is retired for good 😞 It sounds like the RatRig 4 with a newer Duet may be top of the list. I have a LOT of the bones left over from my old CoreXY. Not least of which a REALLY sweet industrial 24 volt PSU I scored.

@br7408 no, not dual rails. Just one at each end of the Y axis.

No dampers, I have double shear stepper mounts.

@Tinchus said in Emergency stop being triggered on 3.5.1?:

And this configuration was working ok under 3.4.6 for at least 3 months.

You could try rolling back to 3.4.6 to see if it is resolved there.

@HeidiH I think this may be a problem of how you are calling the macros. If you start the beep macro from DWC, it will run, but if you start another macro from DWC, it will be queued behind the first macro, and only be run when the first macro is finished. This is similar to how when you set a heater temperature and wait for it to heat up from DWC, you can't do anything else from DWC, but you can from the PanelDue. If you call the beep macro from within a print job, then run that print job, then run the abort macro, I would think that would work. RRF maintains a number of separate input channels, and commands are executed sequentially within them.

Ian

Good morning @dc42,

Thank you for your response. Regarding blocking daemon.g, it is clear to me that it is not necessary. It was likely a feeling I had due to the behavior I observed, and I decided to block it to be sure, but I have now removed it from my code.

Regarding "stack," it is probably a mistranslation; I mean the movement queue (M596 P0 or P1).

As for your last comment, I just tried it and still have to use M569 P1 because if I don't use it, it does not execute in the desired times. Even using M669 T0.1 S1, the execution response of daemon.g is slow. Here are the details of how I conducted the tests.

Gcode being printed:

; G-Code generated by INDART3D G21 ; Metric values T0 P0 ; Select Tool G28 ; Home all G0 Z900 M400 ; Wait for current moves to finish ; Macro G1 X0 Y0 F3000 G1 X1000 Y1000 G1 X0 Y1000 G1 X1000 Y0 G1 X0 Y0 F3000 G1 X1000 Y1000 G1 X0 Y1000 G1 X1000 Y0 G1 X0 Y0 F3000 G1 X1000 Y1000 G1 X0 Y1000 G1 X1000 Y0 G1 X1000 Y0 G1 X0 Y0 F3000 ; The gcode keeps repeating these commands hundreds more times

daemon.g modified with your instructions:

; M596 P1 if (state.status == "processing") && (sensors.gpIn[1].value == 1) && (global.DaemonActive < state.upTime) M106 P3 S1 set global.TimerPelletsT0 = state.upTime + 6 echo >>"0:/sys/Alimentador Registro" {global.ContPelletsT0} ; Log of number of unsuccessful attempts while state.upTime < global.TimerPelletsT0 ; count off the fill time if sensors.gpIn[1].value == 0 ; Check for pellets M106 P3 S0 G4 P500 ; M400 ; Perform a short wait before checking if sensors.gpIn[1].value == 0 ; Check that it was not a false detection set global.TimerPelletsT0 = state.upTime - 6 M300 S5000 P500 else ; A false detection was detected, continue. M106 P3 S1 G4 S1 ; M400 M106 P3 S0 set global.DaemonActive = state.upTime + 20 ; set the new time to allow compressor refill if sensors.gpIn[1].value == 1 ; is hopper still empty? set global.ContPelletsT0 = global.ContPelletsT0 + 1 else set global.ContPelletsT0 = 1 if global.ContPelletsT0 > 10 set global.ContPelletsT0 = 1 ; M596 P0 M25 M291 R"Material Sensor" P"No Pellets detected" S2 T0

The result I get is the same. Right now, I am testing with an empty system, so sensors.gpIn[1].value is always equal to 1. The issue is that without using the secondary motion queue, it does not respect the 6 seconds, it always takes longer than desired, and it always turns off or on at the end of the complete Gcode lines, despite being fragmented with M669 T0.1 S1.

Best regards,

@Phaedrux is like you said. "Problem" solved. Thank you very much.

Ian

Aye I will start a whole new thread and might well take you up on your offer of the CONFIG file at least it is a starting point 😊

Ours is a little bit of a 'rat's nest' of wiring . . ..

Not today's task..

Alan

@T3P3Tony I have a meeting a super long time ago with the trinamics team, it was the time were they were just launching their drivers. They made to me a presentation, where they showed me on a screen how sensitive was their torque detection on a common nema17 motor. I clearly rememnber thatn even a very soft touch to the motor axis using my finger, was being detected by the driver and shown on screen.
This is basically the stall detection capabilities.
I have a long no started idea to try to tune the 5160 drivers on the extruder to be able to detect a change on pressure change while extruding. I managed to do something (not finished) but woulkd it be possible for you to access directly thjrough firmware the driver data and detect these torque changes?
This would be my idea on how to do it with your actual hardware. I think It would be possible, trinamics offers its API of their drivers to work on such features too.

@oliof i have already add for windows
and thank you

@droftarts okay. will do. Thank you.

@aytact What board are you trying to connect it to? The reason the cable comes with no connectors is because there is a range of boards, with different connectors, to connect it to. And whatever length of wire we supply, it will be either too long and need to be cut, or too short and need to be lengthened!

Mini 5+ - this has a 2-pin Molex KK connector. Crimp those on the CAN wires. These are supplied with the Mini 5+.

6HC/6XD - these have an RJ11 socket. If you don't have a crimping tool, you can cut a telephone cable/ADSL cable (usually RJ11) and solder the CAN wires to the middle two wire of the RJ11 socket. If you don't have a soldering iron, get some "Heat Shrink solder sleeves" for 24-26AWG to make the connection.

For power, crimp spade connectors on to the ends. See https://docs.duet3d.com/en/How_to_guides/Wiring_your_Duet_3#crimping-the-connectors

Ian

@DonStauffer that also makes sense.
Thanks for your input, I will keep that in mind when starting to implement this for my future machine.