@chrishamm Another user experience the same issue described above (you can read about it here https://forum.duet3d.com/post/227680), so @jay_s_uk and I put our heads together and tried to narrow down the failure circumstances and find a consistent fix (simply uploading a new DWC*SD.zip does not always work).
What we have discovered is that if the current install/SD card has gone through a number of release upgrades (eg 3.1 through to 3.3b3) it is likely that this Z-Index issue will arise after installing the plugin. Under this scenario I have also experienced complete plugin installation failures.
The resolution is to remove the SD card, wipe the WWW folder (& dwc-settings.json for completeness), and manually replace the WWW folder with a fresh copy extracted from the DWCSD.zip release file. Then once back up and running, re-install the plugin. Simply re-installing DWC by uploading a new DWCSD.zip will not resolve the issue.
This leads us to theorise the following:
There are redundant/left over files in WWW from previous upgrades which are contributing to, or causing this issue.
If (for whatever reason) a plugin install fails, it does not always fail gracefully, and can corrupts or leaves files in a non working state.
I appreciate this is somewhat speculative (correlation is not causation and all that jazz), but it may help you with the continuing development of the plugin system.
Under normal circumstances RRF requests daemon.g from DSF every second. If you have a G4 S10 in there the macro file will run longer so it will not be requested as frequently. RRF buffers up to 16 macro codes and 32 print codes (configurable in config.json). It does not cache entire files so when a trigger is executed, RRF has to wait for instructions from DSF first. Codes are pre-parsed by DSF and encoded in a binary format before they are sent over to RRF.
As "over-engineered" as duet boards usually are, I'm surprised they only provide a 3A on the 5V line. With typical duet engineering, and especially with the over-powered duet3 board, I wouldn't have been surprised if 50 watts were available. 😉 Anyway, the result seems to be that having a PanelDue and Pi4 both feeding power from the Duet3 is probably a bad idea. (I'd suggest that this be added to the wiki. It's likely that the same issue would occur with a Pi3.)
There is no need to worry here. That's what I run as my development environment all the time. I have a Duet 3 with a RPi 4 powered by the Duet as well as (varying versions of) a PanelDue connected to it. The increased power requirement for the RPi is only true with attached USB devices. The Pi itself does not draw very much current or at least well below the 3A it is rated for.
Of course if you populate all 4 USB slots with USB harddrives (preferably spinners) things look different.
I switched to a SanDisk Extreme 128GB card and that totally cleared up the issue. This is one that I use for recording 4K video.
The card I had before was a Kingston 16GB card I got with the Pi.
I'm happy that I figured out a way around this, but I'm surprised that the async/await programming constructs don't protect us from I/O flakiness!
The file is wrapped in a StreamWriter that should have a 4K buffer
The whole call chain is async/await. Log writing doesn't have to complete before the next GCode instruction executes (at least from what I can read without debugging it).
I was going to suggest keeping a queue of logging data and writing it on a separate dedicated thread for I/O. But StreamWriter is basically that. (the only difference being that the log time can be captured without trying to lock the file)
So yeah, not sure how the code should change. But if you are having problems, get a FAST SD card.
Everything compiles fine with just dotnet 5.0 installed.
I also took an hour to grab the August 2020 RaspPi OS 64-bit image, set it up, updated it, adding the duet servers, and installed DSF on it. It seemed to pull arm64 (aarch64) binaries via apt and they work fine. (I didn't try to recompile with arm64, but I don't see any reason why the compile wouldn't work.)
At this time, I'm not sure if there's any advantage to using the 64bit distros with DSF. I didn't notice any, but I only went to far as to installing it and making it sure it talked to my printer. Once I saw that chromium is just as resource hungry on arm64, I pulled that sdcard out and put back the 32bit one.
I think that's all the questions I posted above, so I guess I'll mark this as solved.
@garyd9 The +, is not valid for filenames and directories.
Without context, it's difficult to reply. However, it IS, in fact, perfectly legal in DWC (when used with a standalone duet3), with PanelDue access, in the linux ext4 filesystem (used by the RaspPi when in SBC mode), in FAT32 (used by a standalone Duet2 or Duet3), and NTFS (the filesystem used by the operating system I'm accessing DWC from.)
You linked to a site that references "characters to avoid" and "commonly illegal characters", but the information is quite dated. See my above comment. The only filesystem I can think of off the top of my head that doesn't allow a plus sign in a filename is, perhaps, FAT16/FAT12 (8.3 filenames.)
In fact, when I rename a folder to include a plus sign in DWC (duet3+sbc) the actual directory on the raspPi is properly renamed with a plus sign ("/opt/dsf/sd/gcodes/PLA+") The issue is that DWC/DSF gets flaky when trying to access a folder with a plus sign in it.
Again, this works perfectly fine on a standalone (non-SBC) Duet3 installation with RRF 3.2.
Finally, even if was illegal or if DSF will never implement it, the point of my message was to report the buggy behavior. If DSF won't support plus signs, then it shouldn't allow renaming a file or folder with a plus sign. That would be much better than allowing the rename, and then pumping out error messages on ANY directory access afterwards.
Just as some background, the REASON it's often called "illegal" (when it's not) is because it's often used in command line processing for special things. For example, "copy a.txt + b.txt appended_file.txt", but that would have nearly no bearing on file I/O API's that aren't parsed by the command line interpreter. In those cases, you need to surround the filename with quotes (or escape the plus sign.)
Thanks for that tweak, I'll give it a try on my setup. It may lead to conflicts with plugins but perhaps it's a good idea to start them later anyway using a separate systemd unit.
Edit: It looks like this switch just removes all the default dependencies, which isn't 100% desirable (e.g. it prevents proper shutdown of DCS). But it looks like we don't need to wait for basic.target to be fully started so I'll check which of the underlying units are actually required (probably sysinit.target or at least sub-units of that).
@achrn : I'm also a python newb, and had a use case similar to yours - needing the pi to control other stuff based on the status/values of the DSF machine model. I created a Python service (using pydsfapi) which allows you to monitor the machine model for value changes and trigger the sending of MQTT msgs to a broker for further action in any system of choice. (I posted about it here).
My code leaves a lot to be desired from a Python point of view, but it may be of some small use to you (I hit similar issues with patches and arrays etc)
@the_dragonlord This is a question for the other thread, but I believe execonmcode will only work when using the RPi as the controller in a non-standalone configuration.. I don't see how else it could communicate.
ok, I ask in the other thread. Thanks a lot....I hope to become able enough to use your service on my printer!