Posts made by Ralms

@dc42 said in Drive standard LEDs. What is the max current rating of IO pins?:

@o_lampe @Ralms the MCU pins that drive the IO_OUT pins on the 6HC are each rated to 4mA or more. There is a 470 ohm resistor between the MCU pin and the IO_OUT pin on the connector. So it's OK to connect an LED directly between an IO_OUT in and ground, because given the volage drop of the LED you won't get more than 4mA flowing. However, you may not get enough current to light the LED sufficiently.

When wired like this (or with the LEDs connected directly t the Duet in any other way), a short circuit between the LED pins and the 230V pins on the switch would destroy the Duet immediately.

Thank you for the clarification.

Yes, I'm perfectly aware that 230V would kill the duet, hence trying to be really careful

After some research, I've decided that I will use a daughter PCB just to deal with the switch, where the relay will be activated using something like a TRIAC Optocoupler, completely isolating AC out of the switch.

The reason I was trying to avoid this approach, was to be able to have the switch control the main power relay, without needing a second lower power DC power supply (mostly to lower standby consumption), but it would just be too risky.

@droftarts said in Drive standard LEDs. What is the max current rating of IO pins?:

I'm not sure how the switch going bad would cause a short to this wiring. Maybe I lack enough imagination for types of 'going bad'!

Ian

The switch is like this:

What I meant with the LEDs being independent was to distinguish from more modern addressable RGB LEDs.
All 3 LEDs are built-in in the button, they share a common ground and than have their respective pin.
(the 4 side pins are for the LEDs, the ones numbered.)

My concerns in protecting the LED circuit from a potential short from the AC pins are 2 fold:

• Undisclosed dielectric strength from the seller (typical AliExpress product).
• Possibility of the switch melting for some reason, even though will be carrying around 10mA at 230V AC, resulting in a short due to switch proximity.

Either way, this concern is not specific to duet and maybe its just me being overly cautious.
I will figure it out and if anything ask for recommendations on an electronics focused forum

Thank you

Hi everyone,

I'm working on wiring a power button on my Voron printer, powered by a Duet 3 6HC 1.01 revision.

The power button is one of those anti-vandal switches, but has 3 independent LEDs built-in (Red, Green, Blue).
Being an AliExpress product, I had to measure the forward voltage of the LEDs with my multimeter and it reads 1.82V for Red, 2.32V for Green and 2.56V for Blue.

As its essentially individual LEDs, I can't use the dotstar connector and since I have plenty of free IO, I was considering using the IO at 5V and applying inline resistors for each LED.
I plan in limiting the LEDs to 15mA each.

How much current can each IO tolerate? I assume it's not limited by the 5V 3A max rail is it?

Lastly, the switch will be having 230V AC going thru the switch pins, what would be the best way to protect the Duet 3 in case the switch goes bad? Would diodes be enough?
(Please note that the 230V AC will be used to drive a relay)

Thank you.

@engikeneer said in Using G30 S0 inside homez.g fails:

@Ralms so basically, when you called G30 from console, Z was already homed, so the problematic G1 line to move an unhomed axis in your deployprobe.g wasn't an issue? But when calling homez.g with just a G30 in it, the z axis is marked as unhomed before deployprobe.g is called and hence you got the error. Your problematic command was to move z anyway so x and y don't come into it.

My point is that I think the behaviour you're seeing there is fully expected and 100% explainable

You miss understood.
Z is never homed in any of the scenarios I've mentioned (doing Home Z in the UI or calling G30 in the console), only X and Y are.

So yes, my G1 move in the deployprobe.g was a problem always as it was trying to move Z20.

The issue I'm raising now, is that G30 will execute from the console, even if deployprobe.g fails, it just ignores it and that should never happen.

@engikeneer said in Using G30 S0 inside homez.g fails:

@Ralms note that when you call a homing file it first flags the axis as unhomed. My guess is when you did it from command line you had already homed the z axis?

When calling from the console, is just doing G30.
G30 only resets the Z axis and doesn't touch X or Y.
And yes, before calling G30 from the console, I already have the X and Y homed and with the probe in place.

@jay_s_uk said in Prevent docking and undocking of probe during multiple G30 Pn:

@Ralms call M401 to undock the probe and then do all your probing routines. That should prevent it docking it between.
Then M402 at the end

That did the trick.
Thank you!

Need to look into submitting some documentation improvements after finishing coding the printer lol

Hi everyone,

As I continue to program my printer, I've ran into a behavior which I wonder if there is an easy solution.

Essentially, the printer is a Voron 2.4, which 4 independent Z motors and to level it, I call G30 4 times as per the documentation:

Here is the bed.g

G28 ; home
G30 P0 X30 Y300 Z-99999 ; probe near a leadscrew
G30 P1 X30 Y60 Z-99999 ; probe near a leadscrew
G30 P2 X270 Y60 Z-99999 ; probe near a leadscrew
G30 P3 X270 Y300 Z-99999 S4 ; probe near a leadscrew and calibrate 4 motors

The probe is a Klicky probe, which is a switch type probe, but since connected to the 1LC is defined as type 8.
It's set with:

M558 P8 C"^121.io2.in" H5 F200:100 K0 T2000 

To be clear, the calibration is working fine.
However, the printer is calling deployprobe.gand retractprobe.g for every single G30 Pn call, which makes it walk back and forth a bunch of times unnecessarily.

I know that I can essentially use empty deployprobe.gand retractprobe.g files and have my macros called when needed, but I'm trying to avoid this, to not run the risk of having G30 called and not having the probe.
Is there any way flag G30 so it doesn't call deployprobe.gand retractprobe.g?
Or something like the macro parameters that I can send to G30, where it in turn does a pass-thru of the unrecognized parameters to deployprobe.gand retractprobe.g?

Thank you

(Board Duet 3 MB6HC, with 1LC running firmware 3.5.2 )

@droftarts Thanks for confirming.

The issue I had in my deployprobe.g was that I was trying to raise the gantry in absolute mode without having Z homed yet.
The goal of raising it is to avoid the probe hitting the bet when its attached.

Regarding G30, yeah, I will be using it without any parameter, its achieving the same end-goal, so I'm ok with it.

I just hope that someone doesn't get caught off-guard by G30 ignoring failures in deployprobe.g when called from the console, as it could mean the probe is not even deployed/attached and than the printer rams the hotend into the bed waiting for a trigger.
This is a very niche scenario and would require the probe to be setup incorrectly (normally open instead of the more reliable normally closed and opens on trigger), but still, its a possibility.

@chrishamm said in [Bug] Using G30 S0 inside homez.g fails:

@Ralms I highly doubt there is something wrong with G30. Do you have a deployprobe.g and/or retractprobe.g? We also need to know what kind of probe you have configured.

Well, I stand corrected, with you asking about deployprobe.g I remembered that I had some old draft gcode there and was the source of the error.
Removing the gcode from that file, allowed G30 to execute.

Still, doesn't explain why G30 will execute when called from the Console, ignoring an error at deployprobe.g.
Which is concerning, as it leaves the possibility of having the printer probe the bed without the probe being ready.

Regarding your question, about the probe, I forgot to share it but, essentially its a Klicky probe, running as type 8 due to being wired on the 1TL.

M558 P8 C"^121.io2.in" H5 F200:100 K0 T2000 

@jay_s_uk Just to finish on your insistence in how I was running G30.
Running any of the mentioned configurations for G30 works and probes the bed successfully, that being G30, G30 S0and G30 S0 Xnnn Ynnn Z-9999.
However, specifying S0 parameter will execute anyway, probe the bed and set Z, however throws error Error: Number of calibration factors (0) not equal to number of leadscrews (4).
The same thing can be said for the parameters X, Y and Z, they are all just ignored, but return no error.

So yes, you were right that S, X, Y and Z parameters should not be used with G30 in this scenario but they were not the source of the issue, as I showed that even running without them would fail anyway.

@jay_s_uk said in [Bug] Using G30 S0 inside homez.g fails:

@Ralms you can't use X and Y coordinates in a G30 without a P value...

It's irrelevant, I just showed you that running G30 without ANYTHING ELSE, also fails....

@jay_s_uk said in [Bug] Using G30 S0 inside homez.g fails:

@Ralms you're using G30 incorrectly
it should be a single G30 with no other parameters
There are lots of us that don't have Z endstops and only use a probe.
I suggest you revisit the information about G30 in the gcode reference manual https://docs.duet3d.com/en/User_manual/Reference/Gcodes#g30-single-z-probe

I'm not using G30 incorrectly, I know the documentation and I've read it like 5 times troubleshooting this.
It says

G30, G30 S0 or G30 S-4 or lower are just normal probes. When the probe is triggered, sets the Z coordinate to the probe trigger height.

and as any other configuration in RepRap, you can either let it use the defaults or be specific, I'm being specific here.

Still, I've tested with G30 only, same error.

@gloomyandy said in [Bug] Using G30 S0 inside homez.g fails:

@Ralms said in [Bug] Using G30 S0 inside homez.g fails:

Error: in file macro line 5: G1: insufficient axes homed

The error you are seeing is being reported as being with a G1 command, not with a G30 command. Probably this line in your homez.g file:

G1 X{var.bedCenterX} Y{var.bedCenterY} F5000

This almost certainly means that for some reason when you are running the homez.g macro your X and/or Y axis has not been homed correctly. You should probably check your X and Y homing files (and possibly homeall.g) to understand why they are not working.

It's not, the printer executes this G1 command and stops only after when is about to run G30. I've tested this.
Also, at this point both X and Y are homed, so this G1 command should be valid regardless.

Lastly, doesn't explain me running "G30 S0" on the console executing and throwing the error on itself.
What I suspect is happening, is G30 calling G1 itself internally or something around those lines.

@gloomyandy @jay_s_uk To reduce any further discussion on your arguments, I've went ahead and
empty my homez.g, having only the "G30", as such:

; homez.g
; called to home the Z axis
G30

Literally, nothing else and it fails anyway with the same error.

@dc42 Could you please confirm if this is in fact a bug or some nuance? thank you

Hi everyone,

Raising the issue which I believe to be a bug here instead of GitHub, as requested by the instructions.

In summary, I'm trying to use G30 S0 to home my Z axis and I'm running into inconsistent behavior.

• Calling Home Z on DWC (which calls G28 Z and consequently homez.g), results in:

  G28 Z
  Error: in file macro line 5: G1: insufficient axes homed
  

• However, calling the exact same Gcode, in the same conditions directly from Console, works and performs the homing of the Z axis.

Here is my homez.g:

var bedCenterX = (move.axes[0].max - move.axes[0].min)/2
var bedCenterY = (move.axes[1].max - move.axes[1].min)/2

M290 R0 S0 		   ; Reset baby stepping

G1 X{var.bedCenterX} Y{var.bedCenterY} F5000
M400                       ; added M400 as a troubleshooting step didn't make a difference 

G30 S0 X{var.bedCenterX} Y{var.bedCenterY} Z-9999 ; I've also tried doing just G30 S0, same result. 
M400

G1 Z20 F6000               ; Lift Z after homing. I've tested removing this, made no difference

The steps to reproduce the issue are:

1. Home X, called on DWC and wait it to finish
2. Home Y, called on DWC and wait it to finish
3. Home Z, called on DWC, fails with Insufficient axes homed error mentioned above.
4. Go to the console and execute G30 S0, works and homes Z, however, it still shows an error in the console:

   G30 S0
   Error: in file macro line 5: insufficient axes homed
   

   After this, all 3 axis are considered homed (and with correct coordinates).

From the documentation, it says, that G30 without P, can be used to home the Z axis and the fact that it works outside of homez.g leaves me to believe to be a bug.

Hardware:

• Duet 3 MB6HC running 3.5.2
• Duet 3 Tool1LC running 3.5.2
• DWC version 3.5.2

Please let me know if I can raise the issue in GitHub or if I'm missing something.

Also, if this is confirmed to be a bug, a workaround to unblock me would be appreciated, as I'm using the probe as a Z limit switch to home, no other option.
Thank you.

@jay_s_uk said in Duet 3 Standalone update from 3.3.0 to 3.4.0 failed:

@ralms https://docs.duet3d.com/User_manual/RepRapFirmware/Updating_firmware#all-other-duet-boards
fallback procedure 2 using bossa

Well, after delaying this process for a few days, expecting a nightmare and headache knowing what to do, it was actually fairly painless.

After flashing the board with Bossa its back to working normally.

Just one suggestion regarding the documentation, the Bossa section is missing a last step just confirming that we are free to reset or disconnect the board from USB and use it normally.

Thank you.

@jay_s_uk And then what?

What would be the expected behavior and what actions should be performed?

@dc42 Hey,

If the DIAG Led is the one right next to the SD Card, its permanently on but dim, never flashes.

Hi there,

For the first time I had an update fail on my Duet 3 board.

I started on version 3.2.2 stable.
I proceeded to update to 3.3 stable:

1. I uploaded the Duet3_SDiap32_MB6HC.bin as instructed in the update notes.
2. Next I uploaded the Duet2and3Firmware-3.2.zip, the upload went fine, the files were extracted and I was prompted if I wanted to apply the update, which I said yes.
3. The update went successfully.

Next, I proceeded to update to 3.4.0 stable the exact same way:

1. I uploaded the Duet2and3Firmware-3.4.0.zip file, the upload went fine, the files were extracted and I was prompted if I wanted to apply the update, which I said yes.
2. After this, I got the progress bar saying something around "waiting for the update" to complete.
3. After 30 mins, I refreshed the page and is unresponsive.
4. Check if the IP for Duet changed, which didn't.
5. Next I proceeded to power cycle the the Duet and still, no new IP and unresponsive.
6. When I look at the ethernet port, is like its not coming up, no lights.

What can I do now to recover it?

Thank you.

@chrishamm said in RepRapFirmware 3.2.2 update question:

Upload these two files on the System Files page and confirm potential update prompts:

https://github.com/Duet3D/RepRapFirmware/releases/download/3.2.2/Duet3Firmware_MB6HC.bin
https://github.com/Duet3D/DuetWebControl/releases/download/v3.2.2/DuetWebControl-SD.zip

We're going to add the missing update ZIP file shortly, sorry for the inconvenience.

It's fine, I was using the opportunity to also understand better each component.
So I could even update them separately right?

Uploading the DuetWebControl-SD will update DWC, the Firmware .bins update the boards firmware and I just need to upload the ones I have, while having the SDiap32 ones since I'm doing InApp upgrade in Standalone mode.

Is this correct?

Hi there,

I've saw the 3.2.2 update on RepRapFirmware and I've noticed it fixed an issued I've suffered from:
"[Duet 3 MB6HC] (regression in 3.2) The minimum step pulse width time of the TMC5160 was not always met. This could lead to missed steps when high step rates were used."

I'm just have a simple question so I understand it better the best way to update on Standalone mode.

I've noticed that there is no "Duet3and3Firmware-3.2.2.zip" combined file.

1. Is the combined zip, just the DuetWebControl-SD.zip with the .bin and .uf2 added to it?

2. Additionally, since I only have a "Duet 3 MB6HC", can I just create a zip file of DuetWebControl-SD contents with the Duet3Firmware .bin files for the board and modules I have?
   For example a collection of these files:

   • DWC files
   • Duet3_SDiap32_MB6HC.bin
   • Duet3Firmware_MB6HC.bin
   • Duet3Firmware_TOOL1LC.bin

Thank you for the clarification in advance.

@T3P3Tony said in Duet 3 6HC - Short to ground issue.:

@tony73 thanks, helpful to track the boards that are working well as well.

Hi there,

I have one of these matching boards, serial number WD41269 with those KAXS4 diodes.
Right now I'm using a 12V power supply and the board is working fine, no errors or anything using 5 of the 6 drivers.

My question considering warranty as I do plan switching to 24V in the future.
Will I need to rush upgrading the printer to 24V so I don't miss the warranty time?
I bought the board from E3D a couple weeks back, so it's mostly so I can manage things and plan ahead.

Thanks.

@droftarts You welcome.
I'm glad to provide feedback.

So far I've been pretty happy with the product, even though I was one of the unlucky guys with a board that had those defective diodes pin solders.

Here is a better example of what I've mentioned regarding Microsoft documentation.
Is more common with developer stuff:
https://docs.microsoft.com/en-us/dotnet/api/system.windows.controls.button?view=netcore-3.1

In the end there is almost 2 options:

• On top left there is the drop down to select a version.
  Although this option, depending on how the wiki is organized, might result on a bigger overhead with duplicated pages.

• On the top middle of the page, clearly identifying the applicable stuff.
  In my example page is a Namespace, Assemblies, Classes inheritance, etc, but it can be adapted in this case for multiple products.

You got the point

Thanks,
Ralms.