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

Thanks for the comments

@rodokas I can only work with what I see (-;

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. [provider_sect] default = default_sect legacy = legacy_sect [default_sect] activate = 1 [legacy_sect] 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.

@chrishamm it worked!! Thanks a lot!!

@dc42 it is in the top right on the Plugins page.

@mfs12 I was able to install the plugin, but when starting it up, I get a red popup message; "Failed to start plugin. TypeError: m[y] is undefined"

I got it installed and working. I think it would help to add some clarification on which version is needed instead of just the red X for the version installed. Thanks!

@chrishamm Thanks for the input. I've been doing some testing and thinking.

Unfortunately, when I try your package I get "Installation failed!" - "InternalServerException in InstallPlugin: Win32Exception in InstallPlugin: An error occurred trying to start process '/usr/bin/pip' with working directory '/'. No such file or directory"

I don't have pip installed (though I do have pip3), and both the 'weigh' helper script and the plugin python script are python3. I assume the package handling has decided to try and install python2 versions. One approach would be to let it (i.e. give it a python2 pip and let it get on with it), but that seems a little clumsy if I'm not using python2 versions. Does the plugin system's handling of python and pip distinguish v2 and v3? Does it just try and install both versions if any version is requested?

I notice you've also added a line "sbcPackageDependencies": ["libatlas-base-dev"], and I don't know what that is about - is that a part of the plugin handling internals?

With respect to location of the settings file, I must admit putting it in the system directory is attractive (and hadn't occurred to me), because then the user at the web interface can open it with ease and see what values are set. I have added a default one, but it just has some comments / instructions in it - I think values are too dependant on the vagaries of different load cells to have defaults pre-set. It only needs readSystem permissions (the plugin doesn't write to it, only the helper writes).

[As an aside, the page https://github.com/Duet3D/DuetSoftwareFramework/wiki/Third-Party-Plugins#list-of-permissions lists all the permission names as starting with an upper case letter. However, if I use permission "ReadSystem" I get an error "Invalid plugin manifest", it needs to be "readSystem".]

However, putting the file there needs some additional install steps, because the helper script (which is run from outside DSF) needs to read and write it.

New package

I've made an intermediate package somewhat between my previous and chrishamm's suggested changes. This doesn't use the pip functionality (for reasons as above) but does move the config file. I've also put the helper script into the zip file to slighly ease distribution.

Here it is (take the .txt off before trying to use it): WeighFilament.zip.txt

This has a slightly different install sequence compared to the post at the top of the thread:

Installation

You need some python libraries. At a command prompt: sudo apt install python3-rpi.gpio python3-numpy python3-setuptools (others too, but they are probably already installed).

You need to download and install the HX711 library from https://github.com/tatobari/hx711py This is pure python and relatively straightforward. It appears to be written for python2, but runs happily under python3 as well, so having downloaded and unpacked you cd into the repository folder and python3 setup.py install.

Enable the plugin service on the Pi. See https://forum.duet3d.com/post/219064 (but that says you won't need to do that soon). (Also, I don't think I put apparmor in my cmdline.txt, and it seems to work for me).

Drag and drop the plugin zip file onto the 'Install Plugin' button on the Plugins / External Plugins page of DWC, but don't start it.

At a command prompt: sudo chmod a+rw /opt/dsf/sd/sys/spoolweigh.txt This is so the helper script can write into the configuration file.

At a command prompt: sudo chmod a+x /opt/dsf/plugins/FilamentLoadCell/dsf/weigh This is the helper script and it needs to be executable.

At a command prompt: sudo ln -s /opt/dsf/plugins/FilamentLoadCell/dsf/weigh /usr/local/bin This is to make the helper script easily accessible.

With nothing on the spool holder at a command prompt run weigh zero, this records the tare reading of the holder alone.

Then you need something of a known weight not dissimilar to a spool of filament (preferably nearing the end) - I use a 200g weight - and run weigh calib. It will ask you what the weight is.

Then preferably put an empty spool on the holder and run weigh spool. If you don't have an empty spool but do know what one weighs you can run weigh manual and enter a weight value.

Some semi-cryptic entries should now have shown up in the spoolweigh.txt file in the system directory.

Now you should be able to start the plugin and get a weight readout.

I expect that installing an updated version of the plugin in future will require a repeat of teh subsequent steps above (or extracting the relevant lines from the spoolweigh.txt file first and then adding them into the new one, but probably easier to just redo the steps).

@deme said in Direction/Velocity Vector of Printhead movement:

@dc42 Thanks for the suggestion. A few other questions:

Is there a referance how often the OM can be pulled (in a sec) without losing performance?

I wouldn't advise polling the whole of the OM much faster than DWC does it, which is normally 4 times per second. Maybe 10 times per second wold be OK. However, you could poll just a part of the OM (e.g. the current move direction vector, if we added that to the OM) more often because the amount of data returned would be so much smaller.

Is there a way to force the RRF to parse an undefined axis and stream the values to OM? Or does that make absolutely no sense? For example to do something like that: G1 X10 Y10 U90 for LED Ring Position 90 deg relativ to the x axis.

I can't think of a way to do that using the current firmware.

@mfs12 Thank you! It's not magically faster than using the regular build workflow as laid out by Duet. However, this does automate the majority of the process, so it's faster in terms of human interaction.

@dc42 Excellent news!

@mfs12 Yes solved. Thanks

@mfs12 I could try to help, I have been developing website/apps for years using different language including JS but been away from coding during the last few years ... so I'm likely to be a little rusty.

@dc42 No problem.
There are more problems that need to be solved.
Understand that this can take a little longer.
Ok then I'll send an email with a reference to the post.

Many thanks for the help.

@mintytrebor yes you right, lts just stick with the normal way. And nowdays everthing is connected to the internet even my refrigerator (which a sbit concerning by the way) so it should be fine for the duet, too 😉

@jay_s_uk said in Object Cancel Plugin 1.0:

@joeko which zip file are you use?
Do you not get the prompts to install the plugin?
Are you standalone or SBC?

hallo,
i use this
https://github.com/Sindarius/ObjectCancelPlugin/archive/refs/heads/main.zip
from here
https://github.com/Sindarius/ObjectCancelPlugin
i found the link in the code button

i have read your answer and have looked for an other version and found this
https://github.com/Sindarius/ObjectCancelPlugin/releases/download/1.0.0/ObjectCancelPlugin-3.3.zip
and with this i was able to install 🙂
thx for your answer