Good morning, @droftarts.

I'm going to try using a shielded cable to solve the problem I'm having. However, it will take me a while to do it. I'm also considering adding a small delay before executing the "deploymentprobe.g" command to make sure that the X and Y motors are completely stopped before starting the operation, since I believe they are the only ones that can generate this noise.

I will keep you informed about the results of the tests.

Best regards,

@PCNoobNeedsMajorHelp that SSR should be good for switching an AC mains voltage bed heater.

@Exerqtor OK, so nothing fancy about. BTW: for a similar arrangement (but with separate sensor tip), I use an 'even more ordinary' photo-electric barrier, I.e. without amplifier. Works great. Using the whole nozzle assembly as a sensor induces mechanical tolerances I would better like to avoid during print - just my opinion …

@chrishamm fantastic news on that one. Definitely makes sense to move it out from being dependent on the configtool

Thanks @phaedrux.

It appears to be working now. Before my M401 M402 weren't working either. I believe was on heater 3, used two 4 pin connectors (picture attached).
PXL_20221007_213640912.jpg

I changed the yellow wire to heater7 and changed the number on the one line of code, and M401 and M402 work as expected. Sending G30 the probe now deploys and the effector starts its descent. Now I can work on finishing the setup.

Thanks again!

@phaedrux said in New webcams 2022?:

Raspberry pi W with a cam module and small case makes for a great network camera.. provided you can find a pi.

Yeah my original plan was a Rpi Micro 2 W and a OV5648 connected to it, BUT unobtanium....

It looks like you're using config syntax for RRF3 but your installed firmware version is only 2.05

You should update your firmware.

If you still have access to DWC. Upload these 4 zip files, one at a time in the system tab. Don't extract them first. Reboot after each. Use M115 in the gcode console to verify the firmware has been applied.
https://github.com/Duet3D/RepRapFirmware/releases/download/2.05.1/Duet2Firmware-2.05.1.zip
https://github.com/Duet3D/RepRapFirmware/releases/download/3.0/Duet2and3Firmware-3.0.zip
https://github.com/Duet3D/RepRapFirmware/releases/download/3.3/Duet2and3Firmware-3.3.zip
https://github.com/Duet3D/RepRapFirmware/releases/download/3.4.0/Duet2and3Firmware-3.4.0.zip

That will get your firmware and DWC up to date.

You can see the change logs here:
https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x

For your config, might be a good idea to run through the configurator tool and generate a fresh set for RRF3.
https://configtool.reprapfirmware.org/Start

Backup your existing config files in the sys folder in case you want to switch back to RRF2. It’s easy to switch back and forth, just upload the zip file for the version you want and then upload your config files.

These documents will come in handy during the conversion.
https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview
https://docs.duet3d.com/en/User_manual/RepRapFirmware/Migration_RRF2_to_RRF3
https://docs.duet3d.com/en/User_manual/Reference/Gcodes

@phaedrux
Nice, sounds pretty cool! I would love to see it!

@phaedrux I didn't find that forum post when I searched for this error, weird. Thank you for your help.

This was the fix:
@chrishamm said in MotionWebcamServer plugin - Missing library:

@adammhaile @luckyflyer Very odd, it looks like something changed because this definitely worked for me before on another image. The problem is indeed that motion cannot open /opt/vc/lib/libvchiq_arm.so. To fix this, you can edit /etc/apparmor.d/dsf.MotionWebcamServer and insert a new line below /usr/local/lib...:

/opt/vc/lib/** rm,

Then reboot the Pi or run sudo apparmor_parser -r /etc/apparmor.d/dsf.MotionWebcamServer and you should be able to start the plugin from DWC.

It looks like there is also an issue with Motion's custom log file location for permission:

motion[1762]: [0:motion] [EMG] [ALL] motion_startup: Exit motion, cannot create log file /var/log/motion/motion.log: Permission denied

This is an optional configuration item though so the short-term fix is to just disable the feature.

@t3p3tony, I am still at the waiting stage for the arrival of my killerbee, otherwise I would test this out myself.

My main interest lies in the bluetooth connection, because if this works it will be a much cheaper alternative to the PanelDue or a pendant, at a cost of around £5 (plus a couple of connectors).

The app itself is free, and offers way more control and features, and can be used on an Android smartphone or tablet. It can control the cnc both with up/down/left/right buttons, and also with a really useful touchpad control. My limit of understanding is that the app is 'grbl1.1-compliant'. I'm not sure whether the Duet meets this requiement.

As I said earlier, I have successfully used it on my CNC3018 for a while and find it really easy to use.

1.3.4-beta has just been pushed which adds support for QOI thumbnails

Deut 3 6HC
Duet-3-6HC.jpg
Duet 3 Mini 5+
Duet-3-Mini-5+.jpg

@siam This fixed the issue, thank you.

@codfish124 If your goal is to prevent the bed from moving, just adding diodes won't do the job. They will slow the drop of the bed, but it will still drop. Think about it- the motor only generates voltage/current when it is spinning. If the motor is spinning, the bed is dropping.

Update: Mouser just emailed: Production Issues Reported - Delivery Unknown for the hirose connectors.

So, I made one to use the regular PI4. Waiting for the boards to test.

@dc42 Yes, I know about it. But I didn't have these arduino models in stock. It was interesting to connect the "nano" that I had. And everything worked out...

@run-it
I was wondering how you align the bed for 6 independent nozzles with only one bltouch? First layer must be a nightmare...

It may be possible to integrate with standard RRF. E.g a wifi esp32 polls the extrusion length and controls the flow percentage.

I think that the next step is it evaluate if dynamic flow adjustment provides any value. May or may not be the case.

@dhusolo PanelDue uses 3.3V signal levels, Arduino Nano uses 5V. If you use a level shifter then you probably don't need to change the resistor.

@pfn
Other reason to let the printer manage temps:

slicers put temps command after Tx command so is not possible to manage temps prior to return to print position after change prusaslicer/superslicer have bed temps for firstlayer and other layers but put into gcode the instruction relative to actual selected material so if you have, as exemple, ABS and PETG print with ABS fist layer:110, ABS other:90, PETG first layer: 80, PETG other:70, first object of list in ABS (the one with high temps) then slicer set first layer temp to 110, change to second tool , set second layer temp to 70 and ABS detaches...

@rjenkinsgb Thanks mate, very kind, but I'm not in UK
One of your colonies...

@t3p3tony
STL is uploaded to this site, I couldnt upload the fusion file as its not in the allowed file upload filter, I also didnt see zips allowed so I have a link to it on my drop box.

MFS_newBase.stl

https://www.dropbox.com/s/9e47vm6t26r3db4/MFS_newBase.f3d?dl=0

Thanks @T3P3Tony, that might be part of it too.

I did wonder if I could use the second encoder phase to give direction data to the duet, sounds like it'd require a firmware update. Fair enough.

I have also wondered if the level of precision available for the distance per pulse setting is letting rounding errors build up in this case. But that being said it would be a continuous build up of error rather than one that comes and goes during the print.

I've disabled the sensor again for now so I can get on with printing some larger parts. However I'd really like to get this working as I want to use a layer by layer readout of filament status as a metric for print quality.

The plan is to eventually merge the data with the lower error threshold data logged from closed loop stepper motors to give an overall print quality metric, and indication of where any remedial action might be necessary.

As always really appreciate the level of support from the duet team.

Many thanks
Barry M

Hello

My problem is that my pendant (the same as david's, with an arduino micro) only sends the M112 command, but does not perform any movement via the encoder. My hardware is a DUET3 6HC with SBC and without Panel DUE, Configuration CNC. The arduino sketch was uploaded with firmware 1.8.1 thank you for your help