@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.

@Ant1 Please share the code which intercepts M1000 and calls M291. Does M409 K"state" F"d99fn" show a proper messageBox value when it is not displayed on PanelDue?

@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!

@davidjryan said in DSF 6HC Pi Disconnections over SPI:

The last change was to put two separate 24V power supplies on the machine. One is for the Duet 6HC and 3HCs, one is for all other 24V/12V/5V requirements, and the Pi is on it's standalone "wall wart" power supply.

Generally, when using more than one power supply, we recommend connecting the negative terminals (ie GND, not earth) of the power supplies together, especially in the case of mainboards and toolboards connected via CAN. This eliminates the impact of a potential difference between boards where the power supplies are not in phase, or producing slightly different voltages, which can interrupt the low voltage signals between boards.

In an SBC setup, the ribbon cable connects GND between the boards, which should mitigate any potential difference between the Duet and RPi. So check the ground on both the Duet and RPi, and between them. As you're using a wall wart power supply for the Pi, it may not have an earth, so may rely on the GND from the Duet, so check this is a solid connection. It may also help to plug the wall wart power supply into a power socket as close to the power socket used for the Duet PSU, ie not into a separate wall socket, but into the same multi-way power cable.

This should, at least, make sure that it's not a power supply or ground issue causing the errors.

Ian

@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 !

@tristanryerparke Some notes:

Do you need to be able to pause during your injected moves? Pausable macros are terminated when a job is actually paused and they don't resume at the same position. AFAIR the documentation also states that your macro should be able to recover from a pause on its own, so I don't think you gain much by changing to them If you don't need to be able to pause while your custom codes are being executed, consider executing them on the default SBC code channel once all pending codes are gone on File (see Flush command). Codes sent to this channel are not affected by pause/resume. When those codes have been executed, you may resolve your custom code and resume regular file execution DSF generally runs as dsf user. If you turn your script into a plugin, just make sure it has SD write permissions set (see here). If your plugin runs as dsf, it should not require any custom permissions in /opt/dsf/sd either.

@qurt we occasionally measure the maximum step rates supported by Duet main and expansion boards and publish them at https://docs.google.com/spreadsheets/d/1AWA1wLbOaYzxzdQa5LRZvn9rgEk2BuluHy6-_OnD6FY/edit?usp=sharing.

In RRF all motion calculations are done on the Duet. Motion control and communication with expansoio boards are real-time task once the moves have been melded and finalised, and is therefore best done by a real-time processor running a real-time operating system. When Duet+RRF are used in SBC mode, the parsing of GCode commands is done on the SBC so that that Duet is relieved of some non-real-time tasks.

@modl Does your resurrect-prologue.g file home Z? Or do you continue the print without homing Z?

The resurrect.g file includes an absolute M291 command to restore the original babystepping. That should work if the resurrect-prologue.g file homes Z. If it doesn't home Z, then it would be better to set babystepping to zero.

Ian

@chrishamm ok, thanks! I've updated the printer to dev +8 and it is indeed fixed!

@chrishamm
Thanks for the great patch! Your work is outstanding! It's impressive to see the passion and dedication you and the duet3d team put into the software and hardware!

Now that all the show-stoppers are out of the way, we are going to switch completely to duet3 in the sbc setup. Starting with 4 closed loop steppers with 4 1HCL and 4 open loop steppers directly on the 6HC. Also two filament monitors and two IR probes per machine. This will be followed at a later stage by two tool boards and a distribution board per machine. I am excited to see the results.