@UserXY Ich habe es gerade auch getestet.
Repetier host läuft problemlos mit dem Duet 3.

@Phaedrux

The board is more than a year old so no warranty, but regardless I went for the SBC route to just get it running. I realized version 3.3 actually uses the same SD card for SBC and standalone, and the first SD card I used was out of date. I can now connect via the SBC and the versions are matching for sure (all 3.3), so for a while I was relieved and thought I could start production again. But despite being the same version as I used last week my jobs and macros are partially broken, the code is interpreted differently.

I have macros that repeat the same job in a pattern to produce multiple parts efficiently. If I run them as a macro they will terminate after just 2 out of 25 instances the first time I run it with no error being reported. If I run the same macro again it completes the whole pattern, but the first two parts have now been run twice and may need to be scrapped. It's also a wast of time.
If I run the exact same file from the job folder it finishes 5 instances out of 25 and then will not run again because it does not clear the loop variables so they can not be reassigned.

Also all my laser jobs (I have both a milling spindle and a laser mounted) now turns on the laser on the first G0 transport of each job, leaving a long straight line across the workpiece ruining it. Subsequent G0 moves are interpreted correctly.

Plus a bunch of other less critical issues...

I know, I know, the only thing to do is to upgrade to the latest version and hope that this resolves the issues. But I really just want this to run and I don't have the time to spend on it right now and I know syntax has changed for some M-codes in config and homing macros so it won't be a quick fix. I could not imagine that the jobs and macros would be broken just by running SBC mode...

@IndeX4D magnum + will came in handy if you still have!thank you!

@droftarts This is exactly what I was looking for. Thank you so much!

@deckingman I swapped the bed out and nothing happened , started going over every single bit of wiring I will keep it short but basically there's a emergency stop switch on the case and one of the wires was not on all that well. Reconnected it then tried to heat the bed and it heated straight up. I still cannot move my any of my axis but the steppers LEDs now come on so i assume Its just an issue with my g code.
Major relief anyway as I thought there was a far more serious issue with a broken SSR or Relays.

@droftarts ; Tools
M563 P0 D0 H1 F0 ; define tool 0 that used low end X carriage
G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C
M563 P1 D1 H2 F2 X3 ; define tool 1 that used high end U carriage
G10 P1 X0 Y1.6 Z.34 ; set tool 1 axis offsets
G10 P1 R0 S0 ; set initial tool 1 active and standby temperatures to 0C

@JADoglio I tried the 401/402 option first since it seemed simpler than creating another tool which I suspect would have also worked. This option worked as expected. Problem solved, Thanks

You're not the first person to have problems with Unifi equipment. I'm not really sure what's going on there.

@Phaedrux I will give it a try when I return home, thanks for actually replying to a dead post haha

@dc42 thanks for your answer. i think i will write a little python-script to posprocess the g-code.

Thank you, I will see if I can use this function for my purpose...

Since this post, I have tried many MANY more things to isolate & resolve this with no effect.

Including:

Swapped complete board with a NIB board I purchased as a spare Swapped power supply thinking some random power issue Disconnected SSR from board in case there was some leakage back Disconnected PanelDue and remarked configuration from the config.g Swapped to a NIB PanelDue display Direct cable to the primary network switch , eliminating particular port and/or cable issue with existing setup Forced the network switch port to 100 / with flow control enabled disconnect chassis and all other fans (electrical interference ?) Disconnected Hot end heater in case there was an intermittent cable ( its not being heated, these are just motion test macros, but just being cautious)

The board will stay connected to the network indefinitely, until things start moving. Occasionally it will run for several cycles through the motion test macros with no issues, and other times it will disconnect (or the macro get cancelled) within ~ 1 minute. The printer mechanically is solid, and well adjusted, no tight spots , binding or unusual / questionable things. Cables and ends have been checked many times and never show any sign that there is an intermittent connecting.

=__________________________________________________________

This is the ONLY thing I have tried that seems to improve the issue , but I still haven't been able to get 100% solid connection

Swapped to NEW spare motors just on the bench (NEW cables not running near other printer parts) This seemed much better, so I connected back in the printer chassis. I ran a NEW LDO cable the X motor cable away from the Y motor cables & motors in an attempt to minimize crosstalk/EM interference between components.

Question 1)
Are there any known issues with crosstalk or interference, running stepper cables near other motors or longer cable runs (more or less a 2 foot run with X stepper cable running next to one of the Y motors and the cables to both Y motors) ?

Question 2)
What can cause the macros to be cancelled, ( the motors do go to an disconnected state when macro is cancelled)

Question 3)
What circumstances can cause the ethernet port to stop functioning even though the status in M122 shows it as connected

@droftarts Thank You

@sebkritikel my individual IDEX heads are pretty light (two EVA toolheads, can run 20k and more acceleration on other machines) and only run in X (its still an i3 style bed slinger), so I think I am good on the weight front.

I guess I need to actually put an accelerometer on mine since the Klipper test print shows almost nothing in terms of ringing. if that gives me weird graphs, I will go hunt for things that move when they shouldn't.

@RogerPodacter
I don't see where you call the macro to set the led by temp.
There are several possible causes, all of which relate to trying to access a value from an undefined object

You are looping the X number of tools and checking the heater values.
If the tools weren't created in numerical order then using iterations to identify a tool or heater would cause an error
e.g if you have tool0 and tool3 defined but no tool2
If one of the tools did not yet have a heater defined it would cause an error
And if the switch wasn't defined you'd get an error

Daemon.g may start running before config.g finishes, so if the errors appear at startup you may need a variable to exit the daemon until config.g finishes setting everything up.
state.upTime would suffice

It seems like earlier versions of RRF were simply ignoring errors at times, so what "has always worked" could just be in unreported issue that's been there for some time.

@tylersuard said in Web UI not accessible if I leave printer on Pause for too long:

ave you seen this happen to other boards?

I've seen the firmware crash, but not seen the terminal responses you were getting. 3.4.1 is a bit old. There may have been bugs that were fixed since. If you do reset the board, send M122 as soon as you are reconnected and copy and paste it here.

@tylersuard said in Web UI not accessible if I leave printer on Pause for too long:

what do you mean by manually setting the Z position?

I mean that since you will have a print on the bed you won't be able to home Z unless you have a zmax endstop. So you would need to manually set the Z position. You can do this once you have determined the exact layer height you were at by moving the nozzle down carefully to just touch the print and then using G92 Znnn to set the height where nnn is the Z height of the last finished layer.
then if you edit the gcode file to remove all the previously printed layers and start gcode you can start the print and it should resume printing over the last layer.

@JayT changing the M109 command to M104 followed by M116 is a workaround for the bug. The fix to the RRF source code removes the need for the workaround.

I am so eagerly waiting to here more on this, I run 2 Duet3s with bltouch, and I am running out of spare tips 😊

@Jrow my proposal would be to include the webcam PCB on the back of the Z axis of a CNC machine, and to mount the laser level permanently to the bed of the CNC.

The warm up routine would include a travel along X and also along Y, measuring the deviation in Z, then using that to build a grid of Z offset for mesh bed levelling. You could also measure Z backlash and compensate for it.