@chrishamm

I've created a function to subscribe to the OM. It sees some of the error messages but not all of them.

From the DWC Dashboard:

When I try to overtravel an axis, the message comes through to my app and the DWC console. If I try to set a global variable that doesn't exist, the message does not come through to my app but it does show up in the DWC console. If I try to run a macro that doesn't exist with M98, the message does not come through to my app but it does show up in the DWC console.

The terminal screen on the right shows just the 'message' portion of the OM patch once I receive the full OM on the first call, I didn't want to dump the whole patch on each patch iteration, just when a new message shows up.

The DWC console "sees" everything, my app only saw the target position error.

9c0bcc0d-ec44-403a-9c8b-bcbc783ffaed-image.png

Does the source of the command call to the DSF matter (my app or DWC) in determining where the message goes?

@oozeBot Thanks for pointing it out, I just removed the section about gpiochip4. The automatic change in config.json to gpiochip4 was removed last year and that change is already in the latest DuetPi version, so no further changes should be needed at this point if the stock image is used.

@Gamefanatic3D thanks, I have corrected the persistentGlobal.g example.

@chrishamm Thanks! That was it.

Changed the imports and the send.response() and now it works.

With hindsight I then find this change (and some others) had been made at https://github.com/Duet3D/dsf-python/blob/v3.6-dev/examples/custom_http_endpoint.py in early December last year, but I had missed that.

@LindsayC the reason is that the P parameter of M569 expects a driver ID, which looks like a float but is different. To make it easier to generate the P parameter in a macro, in recent versions of RRF we allow a float with a fractional part that is very close to a multiple of 0.1 to be converted to a driver ID. We can't say that it has to be exactly a multiple of 0.1 because 0.1 cannot be represented exactly as a binary float.

Expressions of any type can be converted to string.

@chrishamm thanks for checking the issue.

One thing I observed today: a similar/identical(?) problem exists also with ObjectModel.Global: this ModelDictionary also doesn't contain any entry ... while the variables are available via DWC/ObjectModel-Plugin.

I tried 3.6-beta4 last week, but was not able to compile it - there were some issues with your new SourceGenerator, I will try again when I have more time / finished the basic stuff with DSF/RRF 3.5.

@T3P3Tony Yes, I used the V parameter as you show. And I assume the prior F parameter worked or it would not have found the 3.6 beta files that I specified.

@rkutun Fixed, thanks

@chrishamm said in DSF Failed to serialize code:

@NineMile I think the messages from M291 are too long, so DSF cannot send them to RRF. The maximum length of a G-code is 256 bytes, which is exceeded by your logic, and depending on the number of parameters it's a bit lower in SBC mode due to the way G-codes are transferred. If you reduce the message length, it should work again.

I'm going to change the error message in v3.6 to be more specfic.

Gotcha, thanks for the clarification. It has definitely been fun trying to fit the M291 dialog contents into 256 bytes so yes, some of these could be right up against the limit (I know I pushed some over by adding the J2 parameter on some dialogs while testing with v3.6.

I'll take another look at dialog lengths and see where these need to be sorted out.

Thanks again 👍

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.