Final tests:

For 3.6.0-beta2(.post3) all relevant data-types (float,int,bool,string) worked as expected.

For 3.5.4 with dsf-python-3.5.0 setting string-data and accessing it via "echo ..." also works.

So issue solved for me - merci!
Thx @all for their support to answer questions and find/solve issues!

@chrishamm

With the v flat, the output is the following:

{"key":"state","flags":"d99vn","result":{"atxPower":null,"atxPowerPort":null,"beep":null,"currentTool":0,"deferredPowerDown":null,"displayMessage":"","gpOut":[],"laserPwm":null,"logFile":"","logLevel":"off","machineMode":"FFF","macroRestarted":false,"messageBox":null,"msUpTime":275,"nextTool":0,"powerFailScript":"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000","previousTool":1,"restorePoints":[{"coords":[0,0,0,0,0],"extruderPos":0,"fanPwm":0,"feedRate":50.0,"ioBits":0,"laserPwm":null,"toolNumber":-1},{"coords":[140.418,136.962,248.086,2.000,5.000],"extruderPos":8.9,"fanPwm":1.00,"feedRate":30.0,"ioBits":0,"laserPwm":null,"toolNumber":0},{"coords":[385.000,122.605,249.936,2.000,5.000],"extruderPos":-10.0,"fanPwm":1.00,"feedRate":108.3,"ioBits":0,"laserPwm":null,"toolNumber":1},{"coords":[0,0,0,0,0],"extruderPos":0,"fanPwm":0,"feedRate":50.0,"ioBits":0,"laserPwm":null,"toolNumber":-1},{"coords":[0,0,0,0,0],"extruderPos":0,"fanPwm":0,"feedRate":50.0,"ioBits":0,"laserPwm":null,"toolNumber":-1},{"coords":[0,0,0,0,0],"extruderPos":0,"fanPwm":0,"feedRate":50.0,"ioBits":0,"laserPwm":null,"toolNumber":-1}],"startupError":null,"status":"idle","thisActive":true,"thisInput":8,"time":"2024-12-05T14:41:38","upTime":21767}}

Still no messageBox key inside it...

@fragrama17 I'm quite sure the minor number parameter was an sbyte in early DSF versions. I'll change the parser accordingly. Thanks for pointing this out.

Negative command portions should not be supported so I'll leave that exception there. RRF may be changed to throw an exception, too.

Update: 10-23-2024

After tabling this issue for the past couple of months, we had to revisit it when we performed a major upgrade to our system that caused the issue to come back in full force to the point where our "automatic" workaround (basically, detection of the issue and software reset) wouldn't work anymore.

We replaced a lot of our 24V hardware with new versions of the same devices and went to different, dual 24V power supplies as well.

After the upgrade, we ran into the disconnection issue almost immediately when trying to run the equipment. We would get tens, almost hundreds of TfrRdy pin glitches in matter of seconds and the Pi/Duet would disconnect within 30s. We disconnected one 24V device at a time and ran some tests until we found that a brushed 24V/2A vacuum pump was putting out excessive noise on the 24V wire which was feeding back to the Pi/Duet. We put a capacitor across the pump's terminals and the TfrRdy pin glitches went to 0. We've been running for a couple of days now and we haven't had a single disconnection between the Pi and Duet.

It looks like our problem was excessive noise generated by poor component selection/sourcing. We tested the other pumps and devices on the system and we are seeing varying amounts of noise but none to the extent of that one particular vacuum pump.

I'll mark this one as solved!

No need for this to have a pro or anti microsoft angle to this discussion.

I believe I have replicated it. I put M400s and echos into the pause and resume macros to get more useful information about user and machine position, but I think the M400s caused the issue to not happen.

It appears to occur regardless of how the machine is paused (filament monitor error or manual pause), or which interface resumes it. It appears that all it takes is one pause on the secondary tool. The ones I'm producing currently are small but noticeable, and don't occur without a pause. I believe multiple pauses create a larger shift.

I've confirmed pauses while the primary tool is active do not cause the shifting. I've also confirmed adding an M400 to the end of the resume.g file prevents this shift.

Configuration repo

@timschneider No, there are retractions in the pause and tool change files, but we do not use M207 and G10/11.

@chrishamm thanks! Now everything works fine!

@curieos I've got new builds ready for testing, please DM me if you wish to try them as well (with 3.5.2). I expect they'll be public sometime next week.

@chrishamm I moved everything in a macro and now it works, thanks.

@chrishamm Was xscreensaver installed on the older bullseye image? I'll give that a try when I get into work later, thanks!

@tristanryerparke Yes, that is intended. M98 starts the macro successfully but only as soon as the following action fails you get a generic error message. You need to subscribe to the object model to keep track of incoming messages, then you can handle that as well. See here for further API details.

@Falcounet That did it, thanks!
I had performed:
sudo apt install python3-dsf-python
but didn't include the snippet of that in my post. I guess it didn't matter since I had the older version of dsf-python installed. I do install that version via a script when setting up the Pi/Duet "out of the box". I'll update my script to use python3-dsf-python instead.

Thanks again!

@Falcounet Ok, I try to reproduce error and save snippet but probably I will post the same info like on photo above.

Apart from this, can you tell which way of object model subscription is the best?

Option 1:

if __name__ == "__main__": subscribe_connection = SubscribeConnection(SubscriptionMode.FULL) subscribe_connection.connect() while True: time.sleep(1.0) object_model = subscribe_connection.get_object_model() [...] if script_end == True: subscribe_connection.close()

Option 2:

if __name__ == "__main__": subscribe_connection = SubscribeConnection(SubscriptionMode.FULL) while True: time.sleep(1.0) subscribe_connection.connect() object_model = subscribe_connection.get_object_model() subscribe_connection.close() [...]

Option 3:

if __name__ == "__main__": while True: time.sleep(1.0) subscribe_connection = SubscribeConnection(SubscriptionMode.FULL) subscribe_connection.connect() object_model = subscribe_connection.get_object_model() subscribe_connection.close() [...]

@Ant1 You can now install the python3-dsf-python Debian package or reference it in your plugin provided you're on v3.5 or newer. This package was gratefully provided by @Falcounet.

I do confirm the permission on the socket file being incorrect as there is no write permission for the group :

$ ls -al /run/dsf/custom/getIt-GET.sock srwxr-xr-x+ 1 loic dsf 0 May 12 13:46 /run/dsf/custom/getIt-GET.sock

I think this is related to the Bookworm image.
However, granting the write permission for dsf group makes the request to return HTTP 200 code and I confirm I doesn't get the "so happy you asked for it!" response neither.

This response is being sent to DSF as we can see it in the dsf-python debug lines : send: {"StatusCode": 200, "Response": "so happy you asked for it!", "ResponseType": "StatusCode"}

It is probably one for @chrishamm to look at.

@achrn said in pip won't install dsf-python-3.5.1rc1:

I'm not sure how to install as dsf, given that the account is nologin. There is no password for dsf. sudo su dsf gives me This account is currently not available. Should I just set dsf to allow login and then login as that user and do the pip3 command? I'm a little nervous that doing that might upset something else that uses the dsf use

@Falcounet it would be good if we could document this given how the new version is being a pain.

@chrishamm Sorry I mixed up something: the machines where the "Firmware reset imminent" message is logged are for older machines with the older generation of the 6HC boards, on which we had installed the 3.3.0 RRF/DSF. On these machines still no flash memory corruption has been reported. On the new machines with the latest generation of the 6HC boards (v1.02) we installed version 3.4.5 of RRF/DSF. These newer machines have no "Firmware reset immiment" logging as this output has been removed from the source code. On these newer machines we have incident reports of non working 6HC boards. When analysing the boards we found no hardware issues but the firmware had been somehow corrupted. When we manually reflashed the boards with RRF 3.4.5 everthing was working again as expected.

So my question is how can the flash memory of the 6HC boards CPU be corrupted. Is there any condition or occurance which may lead to this or may trigger an automated firmware update, which may be interrupted when turning the machine off. Currently it looks like that this only occurs on the v1.02 generation of the 6HC boards or only with version 3.4.x of RRF/DSF.

@Falcounet thanks!

@achrn
Thank you a lot ! This was indeed the problem, I didn't have launchProcesses. I removed it at some point because I didn't think it was necessary to run the python script, but since it depends on an external library, that might cause the issue 🙂

Thank you !