@falco22 I think, you don't understand correctly what @MintyTrebor means...
He means, that the job panel in DWC, where you start the job, is not under his control.
After starting a job it is standard for DWC to jump to status screen. MintyTrebor can only change the BtnCmd plugin.
Got it. It may be (likely is) my ignorance of development around vue etc. Is it worth making this more explicit in the guides?
Having said that, my ultimate goal (easy deployment of DuetLapse.py and a convenient way to expose its' html pages) are pretty basic. So , I understand that most would actually know what they are doing and maybe it does not need to be explicit 🙄
Added an auto check for firmware updates feature, which checks GitHub for an updated firmware version when DWC loads, and pushes an alert to the user. The feature can be enabled in settings. Users can also choose to stop duplicate alerts for the same update if desired.
Team Gloomy users can now access the RRF files panel if they choose to dismiss the warning.
Currently, it only shows the compatible version for the latest release.
However, older releases can be downloaded from the sidebar of each plugin page. All releases can be seen there for a plugin.
We are working on listing the compatible version for each plugin as well. Thanks for raising it!
@ratrig0331 thanks for your M122 report. I've seen this issue once before. I am fairly sure it is caused by problems with the accelerometer wiring that result in communication issues between the accelerometer and the Duet.
I still use the integrated input shaper that is integrated in RRF 3.4.2rc1 (2022-07-06), until I read about the input shaping plugin 3.4.1-b1 today and installed it right away.
After about 30 minutes of use, I had several disconnections with the new plug-in, which I did not have with the previous input shaping plug-in from RRF 3.4.2rc1 (2022-07-06), so I rule out problems with the cable.
I then turned my printer off and on again at the power switch.
After that everything was OK and I haven't had these disconnections anymore.
Just for info, maybe it will help !?
----- Original Text -----
Ich nutze bis heute den integrierten Input Shaper der in RRF 3.4.2rc1 (2022-07-06) integriert ist, bis ich heute von dem Input Shaping PlugIn 3.4.1-b1 gelesen hatte und es gleich installierte.
Ich hatte mit dem neuen PlugIn nach etwa 30 Minuten Nutzungszeit mehrere Verbindungsabbrüche, die ich mit dem vorherigen Input Shaping PlugIn aus RRF 3.4.2rc1 (2022-07-06) nicht hatte, daher schließe ich Probleme mit dem Kabel aus.
Ich machte dann meinen Drucker einmal Aus und wieder An, am Netzschalter.
Danach war alles OK und diese Verbindungsabbrüche hatte ich bis jetzt nicht mehr.
I came here looking for exactly what the OP asked for.
It shouldn't be necessary to calculate data from the gcode, since DWC already knows the requested movement of the extruder. A graph showing this and the measured extrusion rate would be a very cool addition. I imagine it would look something like race track telemetry data with a perfect lap overlayed with you are achieving. 😁
I also think it would be really cool if we had a way to manually, but more directly calibrate the filament monitor. Imagine if you could take the moitor out of the filament path and push a length of filament into it, then have a series of messages like this:
Mark filament "X" mm from reference point and press OK (to set 0)
Slowly pull filament through filament monitor and stop with the mark on the reference point then press OK
Measured sensitivity is XX.XX mm/rev
It would be good to be able to choose the length you want to measure. Obviously longer will lead to improved precision.
This would remove any error from printer settings such as steps/mm on extruder or losing extrusion rate at high speeds. To go even further with this, we could then use this data by comparing extrusion rate with extrusion speed and giving us an M592 non-linear extrusion rate line to paste into config.g in the same way we can with a PID tune and M500 to save to config-override.g
I wish I had the skill to write plugins to do this myself, but I do not.
I'll provide an installable zip plugin file in the dist subdirectory, but it's also possible to run locally without DWC, please see the documentation.
I have to proceed with firmware robot kinematics now and will come back in a few weeks for the following topics
load and save config in robot.g
"split chain" support for Open5x
animate G1, connection to firmware to get inverse kinematics information to visualize segments and tool rotations for checking singularities e.g.
maybe it's necessary to split kinematics into an object path and an endpoint path, so I'll enhance the Viewer to design such configurations. Same for closed chain kinematics (like parallel scara)
@pjl Not yet, but moving a lot of our custom code to a plug-in is still our plan - we just had to prioritize other things ahead of it. Hopefully, when we revisit it, there will be many more examples out there for us to learn from.
@mendenmh Thanks for the input, you're absolutely correct about emissivity issues. In this case though, I'm more interested in filament temperatures rather than the nozzle. I will still be doing emissivity corrections on the data. And calibrating a thermistor to an IR sensor reading is quite funny 😁
@chrishamm I have the same concerns about safety, and agree that adapting RRF is the proper way to go. The problem being, that with my lack of C++ chops, when I started going through the source, I got quite intimidated 😓 (honestly it looks like I just wont manage to fit in my time budget, I am hesitant to bother people too much here about this)
If I made a new sensor type, can the data be obtained through the ribbon cable SPI bus or is it too busy and I would still need connect a free SBC GPIO output to an input connector on the Duet? e.g. SBC SPI out -> SPI on the Duet's temperature daughterboard connector (then I suppose in that case I need to hijack the spiTemperatureSensor.cpp, is that all that I would need to mess about with? )
Im not sure I understand what you mean by "configure heater output as a servo pin"
you suggest having my SBC script send M280 commands through dsf-python and then configure OUT_1 as a servo output? If so, cool, didnt know thats possible. Would consider as dubious plan B 😅
OK. Figured it out... It is indeed down to OpenSSL 3.0 - Posting resolution in case anyone else comes accross this issue:
Edit the openssl.cnf file and enable the legacy provider options. eg:
# Uncomment the sections that start with ## below to enable the legacy provider.
# Loading the legacy provider enables support for the following algorithms:
# Hashing Algorithms / Message Digests: MD2, MD4, MDC2, WHIRLPOOL, RIPEMD160
# Symmetric Ciphers: Blowfish, CAST, DES, IDEA, RC2, RC4,RC5, SEED
# Key Derivation Function (KDF): PBKDF1
# In general it is not recommended to use the above mentioned algorithms for
# security critical operations, as they are cryptographically weak or vulnerable
# to side-channel attacks and as such have been deprecated.
default = default_sect
legacy = legacy_sect
activate = 1
activate = 1
Save and reboot.
npm run serve should now work
Note: On Fedora 36 openssl.cnf file is located in /etc/pki/tls - it may vary per distro.