Topics created by JBisc

There was a request to provide Docker support for DSF a while ago (see here) but I see no real benefit for most users. Upcoming plugins for DSF (or rather easy-to-use plugins) will have limited permissions enforced by AppArmor security profiles so I don't see any need for container solutions.

For users who don't want to use AppArmor it may be an alternative to run the plugin services in a Docker container but that will require extra configuration.

I would suggest using fewer words.

"5v power supply problem" is pretty vague. those 4 terms will occur many many times in many unrelated threads. Best to find a specific term that is more unique to the situation.

"DWC ports" might be a better search term. "changing" is a superfluous word that will occur too often in unrelated posts.

Instead of wiring neopixel, just the word neopixel will likely result in more specific results.

We've all gotten used to the contextual awareness of google to find what we want, but generally keyword search outside of google is going to require a bit of search term awareness.

If you want the power of google to search the forum, do as Veti suggests.

And the STEP fieles ofat least 1.0
here https://github.com/Duet3D/Duet3-Mainboard-6HC/tree/master/Duet3_Mainboard_v1.0

@JBisc Thanks for confirming, I'll work out a fix for the next DWS version.

PS: I've got a fix ready, it will be part of the next software release.

@chrishamm Thanks I will try that!

@bearer said in Duet Software in VM:

qemu

Thanks for your tipps. I will try this.

Processing a M98 call requires the file system to read the root directory to find where /sys is, read the /sys directory, then read the sector that contains the start of the macro file. If the /sys directory or the macro file exceeds 512 bytes then additional reads will be needed. If the cluster size is small than FAT reads may be needed too. There isn't sufficient RAM to cache more than 1 sector. So there will be at least 3 SD card reads per execution of the macro. That will be what's taking the time.

try /var/run/dsf/dcs.sock or look in /opt/dsf/confg/config.json

(it'll only be there when dcs is running, and lsof and even netstat are handy for finding files and sockets in use in general)

It seems that the new version of Klipper has potentially introduced some "MCU-stopping" bugs. It could be related to their very interesting "input-shaping" feature.

But yeah, this is on a RAMPS, so I'm really just poking fun. The point is, it happens. 😛

@JBisc

Some fans are stubborn and don't work well with PWM. The blip is intended to kickstart them before slowing the speed

@JBisc said in Simple question: How to read from IO:

@dc42 said in Simple question: How to read from IO:

M409

I remember that you posted in another post that analog values are not included in the current object model

Raw analog inputs are not included, but the readings from configured sensors are:

20/04/2020, 09:55:19 m409 k"sensors.analog[0].lastReading" {"key":"sensors.analog[0].lastReading","flags":"","result":21.5}

@lepetitmort said in Servo error "Response timeout":

How to set the problem/thread on "solved"?

https://forum.duet3d.com/topic/7773/forum-feature-mark-as-question-solved

The easiest way to transfer a file from a PC to the Pi would be to upload it using the HTTP PUT endpoint DuetWebServer provides: https://github.com/chrishamm/DuetSoftwareFramework#put-machinefilefilename

So for example you can send PUT /machine/file/gcodes/mygcode.g with the whole body being the file content and it would be transmitted without issues. I suggest you look for a Python REST API and use that.

I'll try to reproduce and fix the issue you reported about M28.

Thanks for reporting this, I've got a fix ready that will be published as part of DSF 1.3.2.