Do you have plugin.json in the root?
Yup still there
It looks like the zip is created during the build process for the plugin. So unzipping, modifying, and re-zipping it doesn't seem possible. You may need to modify the source and rebuild.
Ahh, that would explain it
@Phaedrux
That's the weird bit. I tried pretty much every compression method that 7zip offers. Only tried .zip architecture though, not any other format like .7z.
I couldn't find any documentation for what type of compression DWC requires, so I am going in a bit blind.
Hi all,
Im currently trying to install the motion plugin on a 6HC + SBC. The current motion version is 3.5.1, where as RRF is 3.5.3 (and 3.6.0-B2 on a few machines)
I thought it would be possible to unzip the plugin, edit the plugin.json file and recompress the files however I am getting this error after compressing and trying to upload
This is without editing any of the files, just un-zip and then re-zip
Does anyone know of what type of compression method is required?
It might sound a bit stupid, but with your M950, have you tried reducing your Q800000 to something like Q3500000
For some reason, when I try to get my neopixel strips working, I can only get them to function with Q values of 8000, and 2800000->4100000
--
Also on the documentation it does say the following:
The Qnn parameter sets the LED clock frequency. This is 4x the bit rate. Most datasheets for LEDs (at least SK6812 and WS2812B based LEDs) suggest a maximum data rate of 800Kbps, so 800000 * 4 = 3200000. The default of 3000000 appears to work well with most LEDs.
@woody
Without seeing a wiring diagram of what you plan its hard for me to say if it will work.
But powering an expansion board like a 3HC with a different PSU is A-OK. One test machine I have has 3 different PSUs (one at 25V one at 30V and one at 42V)
If the expansion board is CAN controlled, then its important to know that power isn't transferred via CAN so you can power each expansion board with its own unique power if you so wanted.
For future reference, if you look at a stepper motors data sheet, they normally have the rated voltage at something ridiculously low like 3.4V. This is the lowest voltage the motor can function with.
Almost all stepper motors can be run well past 60V so you don't have to worry if some amazon listing doesn't have the full data sheet available.
Sounds like the same method I used for filament loading; Push 10mm, then check the sensor and loop until complete.
The only downside I found with that setup was if you don't add a wait into the loop it fills the G-Code buffer so even if the sensor reads true, then it'll still complete the rest of the queued moves past where you want it to stop.
And if you add the wait, you then get a stuttering effect as the movement has to decelerate to a stop for the check to happen. So you don't get a very nice smooth movement and can sometimes sound weird / excite vibrations is the system.
@droftarts
I talked with some firmware Devs a few months ago, and you have pretty much got the bed probing method spot on. They measure the rate of change from the sensor, and when the rate falls below a set amount they class it as the nozzle hitting something.
I believe the biggest challenge with getting this working on Duet hardware via a macro is having a way to probe the rate of change fast enough not to cause the nozzle to embed itself into the bed using a smooth movement.
I'm not the most savvy on conditional G-code, so I'm not sure what interrupts are available.
@woody
Depending on the SSR you have purchased, some require a heatsink, some dont. If yours has an "optional" heatsink, this is actually mandatory as DC relays can get quite toasty.
We use a www.goldssr.com DC relay for our DC beds, and without a W70 heatsink they overheat
Just something to be aware of
You might find it easier to run a DC relay which is controlled by a 24v output of the 6HC.
I have done this a few times to control some unique heaters on some prototype hot ends - this allows 48V to be used without any risk of damaging the main motherboard.
This is a bit of a weird one as I have not been able to isolate if this is related to the updated input shaper motion pipeline, or a pressure advance oddity. I have attached some pictures which shows the magnitude of the under extrusion, as it only seems to appear when the layer change is in an alternative direction to the layer behind, or when placed near/on a curve.
The under extrusion also appears slightly after text, similar to what @Exerqtor witnessed in the early Alpha firmware's with a growing amount of under extrusion after/during text.
Currently this behaviour is consistent between multiple extruder & nozzle combinations, (15mm, 25mm, 45mm melt chamber lengths), and thankfully the under extrusion is mitigated by reducing the amount of pressure advance, however this does come at the expected cost of more bulging on the corners of the rest of the print.
.....side note: reducing any wipe distance in the slicer has also helped mitigate, but this is a band aid, not solving the problem.
The thing that makes this surprisingly difficult to track is that the seam/layer change on certain models is completely fine, but moving the seam to another location on the model can suddenly cause the under extrusion.
One thing that does play in the back of my mind, is I remember reading about someone's tool changer being unable to successfully dock as some of the move commands were being merged with the ones directly before/after. I wonder if what could be happening is if the immediate movements after the layer change are being executed at the same time the filament is being de-retracted causing a momentary amount of under extrusion.
Alternatively, this only slightly explains the under extrusion which occurs after after text is printed, as the constant ramping of speeds could cause an error amount to build up as consecutive letters are printed, resulting in an under extrusion artefact
I am still gathering data for this, but I thought it best to start a new post thread just incase others have experienced this as well.
@droftarts
Not to worry, just logging incase and of the information is helpful.
HI all,
Simple error during a regular print about 20/25 minutes in
Error: Movement halted because a step timing error occurred (code 3). Please reset the controller.
Error: Existing: start=1789869067 length=8828, new: start=1789876874, overlap=1021 time now=1789871627
M122 Report
m122#
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-beta.1 (2024-09-24 10:07:04) running on Duet WiFi 1.02 or later
Board ID: 0JD2M-9F8TA-GJ4TD-6J1D6-3SD6P-16PG6
Used output buffers: 11 of 26 (24 max)
=== RTOS ===
Static ram: 23360
Dynamic ram: 66884 of which 0 recycled
Never used RAM 11944, free system stack 100 words
Tasks: NETWORK(2,ready,14.7%,181) HEAT(3,nWait 5,0.1%,307) Move(4,invalid,0.5%,266) MAIN(2,running,84.7%,713) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 27:19:22 ago, cause: power up
Last software reset at 2024-09-01 17:47, reason: User, Gcodes spinning, available RAM 30728, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 20.1, current 30.4, max 32.1
Supply voltage: min 24.5, current 24.9, max 25.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/816/768, gc cycles 0
Events: 0 queued, 0 completed
Date/time: 2024-11-10 18:19:10
Slowest loop: 376.85ms; fastest: 0.11ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 44.5ms, write time 118.3ms, max retries 0
=== Move ===
Segments created 662, maxWait 60410311ms, bed comp in use: mesh, height map offset 0.000, hiccups added 42 (1.25ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 34135.00/33905/0.92 3194.00/2900/0.16 1881.00/1885/-0.81
no step interrupt scheduled
Driver 0: standstill, SG min 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min 0
Driver 5:
Driver 6:
Driver 7:
Driver 8:
Driver 9:
Driver 10:
Driver 11:
=== DDARing 0 ===
Scheduled moves 18362, completed 18332, LaErrors 0, Underruns [5, 0, 0]
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Movement locks held by null
HTTP is ready with "m122#" in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X233.739 Y193.061" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 1
Code queue 0 is empty
=== Network ===
Slowest loop: 667.84ms; fastest: 0.00ms
Responder states: HTTP(4) HTTP(0) HTTP(4) FTP(0) Telnet(0)
HTTP sessions: 2 of 8
=== WiFi ===
Interface state: active
Module is connected to access point
Failed messages: pending 0, notrdy 5, noresp 1
Firmware version 2.1.0
MAC address a4:e5:7c:03:da:81
Module reset reason: Hardware watchdog, Vcc 3.40, flash size 2097152, free heap 42392
WiFi IP address 192.168.1.197
Signal strength -52dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 3 5 3 0 0 0 0 0
@jay_s_uk Do you know all the possible outputs of state.status?
I cant seem to find anything in the docs.duet3d page about it
@Tinchus From my experience most of the resonance when it is speed specific will be related to any mass that is not perfectly centred on the ball screw (i.e how much of a banana the screw is). The motor will have its own resonance, but its exceedingly hard to mitigate that without straight up changing the type of motor.
Your right to think about changing the tip of the screw from a hard clamp to some form of plastic dampening clamp. it can still hold up the tip and provide a little bit of dampening enough to remove the resonance.
You can see a similar system used on the Prusa XL or our Construct1 XL printers 
(obviously these are threaded rods, but they work the same for ball screws)
A quick way to check if the the led is faulty or the board is faulty would be to run the scanning probe drive level with M558.2. If the code faults it would imply the board is dead or a faulty connection, but if it works it might just be the LED
@Tinchus Download an audio frequency finder and use your phones mic as the input. alternatively you can put the phone against a surface that would "hear" the vibration as this is a quick engineering hack.
Then use the input shaper to try and cancel the frequencies being generated.
However this is unlikely to fix the issue as whipping of a ballscrew is not an impulse vibration but instead a constant generating frequency. the best bet is to either limit the speed via max speed limit, or add dampening to the ball screw.
(this could be adding a bit of slop to the screw, or another item to absorb the vibrating force before it can grow.
If you are using very high quality ball screws, you might be able to get away with constraining one end (if you are using a pillar block setup) and replace it with a compliant spring holder. enough to hold it in position, but also to flex absorbing the frequencies when its generated.)
@jackantubis I love it! super cool.
was there any specific process to pair up the transmitters? Either way that is a very nice minimal way to get a mobile screen!
@AndyE3D Do we know what the M970.1 default 1000 and the M970.2 5000 values are relative to?
The documentation is a bit sparse on how the math is calculated.
@T3P3Tony Very much appreciated.
Thank you!