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.

@Stephen6309 said in DSF 3.2 file/folder naming issue:

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

https://www.mtu.edu/umc/services/digital/writing/characters-avoid/

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

@TLAS said in anyone used Raspi compute module and Compute IO:

FYI, I’d love to see a compute module interface in the next Duet3.1 boards.

We looked at doing this when we designed Duet 3, but the cost of putting all the expected RPi I/O connectors on the Duet would have been very high, even if we did manage to find space for all of them.

Thanks, I am aware (-:

@Donpi Dear myself, try this way :

static void Main(string[] args) { Console.WriteLine("Début"); Console.WriteLine("Connection"); SubscribeConnection oCon = new SubscribeConnection(); try { Task oTaskCon = oCon.Connect(SubscriptionMode.Full,"/var/run/dsf/dcs.sock"); oTaskCon.Wait(); } catch (Exception oE) { Console.WriteLine("-----------------------------"); Console.WriteLine("---- erreur de connection ---"); Console.WriteLine("-----------------------------"); throw oE; } if (oCon.IsConnected) Console.WriteLine("Connection OK"); else Console.WriteLine("Connection échouée"); Console.WriteLine("Recupération du modèle"); Task<MachineModel> oTask = oCon.GetMachineModel(); oTask.Wait(); MachineModel oModel = oTask.Result; Console.WriteLine("Lecture des capteurs"); Sensors oSensors = oModel.Sensors; Console.WriteLine(oSensors.Analog.Count.ToString() + " Analog sensors"); Console.WriteLine(oSensors.Endstops.Count.ToString() + " Endstops sensors"); Console.WriteLine(oSensors.FilamentMonitors.Count.ToString() + " FilamentMonitors sensors"); Console.WriteLine(oSensors.GpIn.Count.ToString() + " GpIn sensors"); Console.WriteLine(oSensors.Probes.Count.ToString() + " Probes sensors"); Console.WriteLine("Capteurs Analogiques"); AnalogSensor oMCU = oSensors.Analog[3]; oMCU.PropertyChanged += OMCU_PropertyChanged; Console.WriteLine(oMCU.Name + " : " + oMCU.LastReading + " C°"); Console.WriteLine("Updating model"); while (true) { Task<JsonDocument> oTaskPatch = oCon.GetMachineModelPatch(); oTaskPatch.Wait(); oModel.UpdateFromJson(oTaskPatch.Result.RootElement); Thread.Sleep(250); } } private static void OMCU_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e) { AnalogSensor oMCU = sender as AnalogSensor; Console.WriteLine(oMCU.Name + " : " + oMCU.LastReading + " C° from event"); }

Thanks for pointing this out, I'll change DSF so M21 doesn't return an error message for SD card 0 (which is the default for M21).

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)

@oozeBot said in Timelapse video through execonmcode!:

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

Many thanks for clearing this up! I'll dig through the DSF docs for the primary "Code" packet syntax in the long term and ask away with questions if something comes up.

So just to get this right: You want to move to a certain position in a macro file, call some arbitrary code to switch something on/off and then resume movement?

That's mostly right! I wasn't planning on doing this from a macro, just by simply sending a stream of GCodes on the socket connection.

Huh, this is a clever solution, and I might play around with it. But, now that you mention that the object model synchronization isn't real time, it may be that I'm simply building this application on top of the wrong interface. Something as simple as getting an "OK" from an M400 from an interface that invokes the motion planner would be totally sufficient.

Thanks for pointing me in the right direction!

@chrishamm OK, no problem. In the mean time, I'll go through the latest DSF commits and checkout what's already there.

@PCR said in Install DSF on a Kernel <4.8 | GPIOCHIP missing:

Cannot put line into event mode

seems the pin does not support interrupts?

you can change pin in /opt/dsf/conf/config.json

@gtj0 work is ongoing on DWC etc right now. I am sure your pull requests will be considered as part of 3.2 beta.

@kaoshihchuan the following two links will help you understanding the new object model of RepRapFirmware version 3 (RRF3):
https://duet3d.dozuki.com/Wiki/Object_Model_of_RepRapFirmware
https://duet3d.github.io/DuetSoftwareFramework/api/DuetAPI.Machine.MachineModel.html#properties

In the first link is explained, how the Duet can be accessed and explaining of the json structure.
You should use the current RRF version (today: 3.1.1).

Ah, figured this out. It looks like the request to enter "command" mode must also include the protocol version.

j=json.dumps({"mode":"command", "version": 8}).encode()

The server picks up the missing field as 0 and closes the connection immediately.

It looks like this isn't stated yet in the Duet Software Framework docs, but I got a pro tip from @wilriker on this thread.

Thanks for the breadcrumbs everyone!

@chrishamm Cool, thanks!