charge pump

[A Former User]

interesting idea, had similar setup with LinuxCNC and Gecko G540 and when moving to the Duet3 this was no longer an option.

is the safety board a COTS or DIY thing?

[Danal]

@T3P3Tony said in charge pump:

out of interest what are you controlling with the charge pump?

@smece said in charge pump:

totally separate "safety" electronics that have independent current measurement, temperature measurement, water flow measurement and charge pump input,

I'm reading this as pulse output from firmware on Duet (NOT hardware, as he said), that inputs to the safety controller. Pulses go missing... within short period, safety control E-Stops.

This is quite common on CNC back in the days of proprietary / dedicated controllers, and was carried forward to many pieces of the MACH (one of the very first PC based CNC controllers) hardware infrastructure. Many break out boards had it, as an example. It has been slowly dying off with things like TinyG and GRBL and PlanetCNC. Like @smece , I'd really rather see it keep going. It is a very solid "fail-detect" architecture.

[A Former User]

Or dying off as a general result of integrating the drivers with the controllers with nowhere send the charge pump signal?

[A Former User]

@bearer said in charge pump:

is the safety board a COTS or DIY thing?

almost all aspects ATTM are DIY (even the mesa board is not mesa board but something I'm making with a friend based on virtex fpga but bitstream is based on mesa one) .. so safety board will be a DIY thing for sure .. the idea is to pack monitoring and safety on one board so ESP32 will handle visuals (ESP32-CAM) and the wifi connectivity, the "brains" will probbly be some stm32 cortexm0 reading bunch of sensors (temperature, water flow, currents, air pollution...) reporting that to questions from ESP and killing the main power "in case of a problem" + activating the alarm (especially in case air pollution sensor picks up something as that indicates fire) ... we'll see, I'll try to make something universal anyone can use / upgrade .. maybe I scrap the esp+arm idea and go to some opi/rpi shield and write sw on opi/rpi to handle all that.. that can give me a fancy display and allow for multiple cameras etc etc.. will see ... for now the issue I have is I have no clue if the electronic is working ok or not and there's not much in way of EMI protection on duet2, have not seen duet3 yet but I doubt it's uber protected so.. mcu's get stuck, bits flip, shit happens.. I've seen stuff .. stuff that would make your blood freeze ..

[A Former User]

@T3P3Tony said in charge pump:

what are you controlling with the charge pump?

the idea is that you have to turn the pin on and then off and on and off programmatically (so not just set hw inside mcu to do it automagically) .. on the other side that's detected as "electronics is operating properly, it's not frozen, stuck in dead loop, running wild" ... so that signal is fed into the "security control board" that I'll be designing that will in case charge pump is dead turn everything off.

so, what I'll be controlling... answer is "everything"

[zapta]

@smece, what exactly are you looking for, a periodic OK signal from the duet's firmware to reset your watchdog timer?

[A Former User]

@Danal said in charge pump:

This is quite common on CNC

It is still common on CNC machines, new, expensive, huge, complicated, modern ones .. you can't find it on PRC stuff but.. PRC and safety is a very different discussion

@bearer said in charge pump:

Or dying off as a general result of integrating the drivers

well integrated drivers don't really cut it on proper cnc machines .. not much point in integrating 3kW or 5kW driver on a same board as your stepper generator is .. they are just not present on the puny stuff we normally use for 3d printers and mini pcb mills, laser engravers and other hobby eq. we normally operate with... it's rather a must on professional machine (does not need to be a charge pump, there are other keep alive systems out there, this one is just simplest to implement) ... and when you have many hundreds of kilograms on the move by kilowatts you really wanna think about security

[A Former User]

@zapta said in charge pump:

@smece, what exactly are you looking for

hm, I think term "charge pump" is rather explained well already, it's a concept that's used for numerically controlled machine from the start and is used still ..

a periodic OK signal from the duet's firmware to reset your watchdog timer?

I need a way to know that duet is running ok and I need that way to be, on my side, detectable without MCU. With a charge pump the pulses are charging a capacitor, very simple circuit, diode and resistor from the charge pin to cap, bleader resistor over cap and an opamp 1:1 after the cap before the comparator circuit that checks if cap voltage is between 2 set points. If the voltage go below or over the setpoints -> ERROR

[Danal]

@zapta said in charge pump:

@smece, what exactly are you looking for, a periodic OK signal from the duet's firmware to reset your watchdog timer?

Yeh, the key on the SEND side is that it come from the actual firmware, not an outboard circuit, not a PWM capable pin, yes from the 'main loop' in the firmware so you know it is fundamentally alive or not. There are many protections built into (most) firmwares. This is a 'last ditch' or 'most fundamental' monitor.

The key on the RECEIVE side is simplicity. As @smece said, as simple resistance/capacitance circuit, NOT another piece of firmware counting pulses. The simple RC circuit is, in turn, wired in a very simple, 'physical override' fashion to cutting something fundamental if the pulses go missing. Often power.

It is a fair point that 'one board solutions' with drivers on the board may need Charge Pump final safety net somewhat less. Maybe. It would actually be nice to see this built into the onboard stuff as well as available for external drivers.

It is absolutely a good thing, with years of proof behind it, for large dangerous machines. If Duet wishes to be considered as the controller of large external drivers on equipment like this, Charge Pump output would be an important thing to improve the chances of selection.

[A Former User]

Sure I get the high power more safety thing, I just didn't immediately see where the Duet board beats LinuxCNC when not using the integrated drivers; for an integrated board a the watchdog gets you 90% of the way there, but with regards to safety 10% will kill you no problem:D >.<

[A Former User]

@bearer said in charge pump:

where the Duet board beats LinuxCNC

simplicity

I'm currently using linuxCNC .. for starters, I hate python, doing anything on linuxCNC without python is nightmare... I'm also currently using mesa based stepper generator connected to the linuxCNC with ethernet cable. Again, works like a charm but for e.g. these drivers I have talk modbus and maybe can (need to check about can) .. I have not decided I'm moving this machine to duet3 but I'm considering it and I noticed that charge pump does not exist. Should be super simple to set up (just ad toggle pin in the main loop, if such thing exists in RRF or add a thread in RTOS that does that or .. do not know the structure of RRF to say where's a good place, I'm sure there are ppl that do) ... without charge pump, I'm 100% sure I will not use duet on that machine, with charge pump it comes into consideration.

The second reason I'm considering duet is a homogenization of the environment. I have here many RAMPS, SKR, GENx boards that can run MARLIN, I have 2 replicape's and 2 DIY replicate-like boards, all are in drawers, number of them were used on some printers at some point in time, I kinda moved all my printers to smoothieware 'cause for me that was the least worse solution available and I homogenized printers to it ... now I'm in process of testing duet and I love the hw, first time I looked at the sw (some years ago) I hated it, don't remember why, need to refamiliarize myself with it but if I end up liking the RRF3 source (I already like the hw) I will probbly homogenize to duet and in that case, I wanna run my CNC off duet if that's possible... The "best tool for each task" is a good approach, especially if you do it professionally, but this is hobby for me and using single tool I know the good that gets the job done acceptably is kinda perfect for me .. I will homogenize here as much as I can, and I will move away from smoothieware, I will NOT move to marlin 2.0, so from the research I did so far the two interesting systems are KLIPPER and RRF, both have + and - ... klipper allow me to use all my hardware and the whole concept is great, the problem with klipper is that python disgusts me so I'm avoiding it, hence duet is in the lead

So it is kinda "personal preference", if klipper devs didn't use python but c++ for the main code I'd be bugging them now and would probbly have duet hw in my drawer instead on printer

[A Former User]

Gotcha. If you're not needing it for production and not "right now" it might be a good fit - if the charge pump situation is resolved.
By that I mean I'm converting my (tiny!) cnc router to Duet3 and finding RRF3 lacking with respect to probing - but conditional g-code is coming to a beta version near you very soon, and possibly G38.n is sort of holding back the show. There are other probe commands, but in the limited time I've spent on it after the initial head scratching, I've not found a personal preference I'm happy with. Hopefully time and life allows more poking soon.

I would certainly throw together a simple charge pump detector* for the spindle contactor if this was available, and it would be interesting to see what Tony and David think about adding something, possibly even to the integrated drivers/heaters in due time. It would up the cost and board real estate but with the external mosfets the Duet3 is quite capable, even more so if they supply separate and higher voltage for the motors in the next iteration.

Homogenization can be a good thing, especially when done right, i.e. Duet, couldn't agree more with you there, and hope to see RRF with proper big boy pants:)

[A Former User]

Another thing that comes to mind when you say many hundreds of kilograms on the move is homing.

(Bear in mind I have no experience with this on a large scale, and there are certainly more gaps in my RRF knowledge than a fine swiss cheese)

To the point ... there seems to be no deceleration for a G1 H1 move which is basically what you would use for homing, it moves till the input is asserted and stops hard. I can only imagine that some level of overshoot is needed when moving a large mass at any speed. Even on my tiny router, the low mass and (relatively) high rigidity makes for real slow homing or real loud stops.

To work around it I try to always send the machine home before powering down reducing the homing sequence to slowly backing off the limit switches just a touch, and slowly creeping up on them again. Maybe thats how it needs to be but, but I'd love to see a setting per axis that says use up to this amount of travel to come to a stop as most limit switches will have some sensing distance, or could be mounted to allow traveling past them.

Maybe this is a non-issue if the external drivers can be tuned to accomodate this?

[A Former User]

@bearer said in charge pump:

is homing

TBH none of my CNC machines do home. I put a stock material where it's convenient and then select a corner, either with edge finding tool or with a microscope/camera and set that point as 0,0 or whatever point I wish..

There are some things proff. drivers can do, for e.g. if I put a pcb I have 4 feducial markings, I select those 4 points and machine twist, scale, rotate existing g-code to fit those 4 points in 4 required positions before drilling holes... no clue how is that done exactly but what I understand is that a new coordinate system is created based on those 4 points and then regular g-code is run... never did that myself so ...

now, since this new machine is supposed to do bunch of stuff homing will be required and my idea is to use 2 limit switches per side + homing sensor one side of each axis, so you run fairly fast till you hit first switch (~20cm from the edge) then you run slow till you home to optic or piezo, and if you reach second limit switch the whole machine shut down and breaks engage ... or not, the breaks thing will have to be decided later, the big red button + long red leg rod will just cut the power and maybe engage the breaks, second limit will cut power, maybe engage breaks, dunno .. problem is when it's moving towards you and someone wanna save you and hit the stop if there are no breaks you are injured anyhow, on the other side, if you are pinched and you press stop you are still pinched if the breaks are engaged .. maybe some 2 stage thing we'll see .. also attm X is 3kW without break and Y is 5kW with break .. Z is not decided yet (I have some 8A nema 34 stepper, but I seen some cute 1kW servo's that are lighter but expensive .. we'll see.. still a long way till Z motor )

with printers, dunno, all my printers are rather small today, my big printer is in garbage unfortunately and my biggest printer will in few days be that e3d toolchanger thingy.. I do maintain for friends 2x wanhao d9 500 and 1x cr10 500 but those are not mine, and on that big of a printer regular print last 3-4 days, who cares if it takes 1 minute to home ... and these small printers I have up to 300, homing in worse case takes a minute

[A Former User]

This is where my limited testing and knowledge is revealed; that would require you to ensure the first switch stays triggered for the whole remaining 20cm, and it would still do a hard stop when this switch is met (maybe the motion planner will take the next move into account?) , this is why I'm saying "get someone who knows what they're talking about to chime in"

Edit: on the printers with low mass and some flex in the belts, its a non issue. Higher mass and ball screws changes that "a tad".

Edit2: does not seem to be much if any difference in using two endstops, the first seems to come to a full stop while the acceleration/jerk settings are observered for the next and slower move towards the last endstop.

[dc42]

Using a charge pump fed by a software-controlled pin can indeed been a good safety system. However, embedded processors such as those used the Duet have watchdog timers. Any situation in which a charge pump would signal failure would also be handled by the watchdog timer, except for sudden catastrophic failure of the processor. The processors used in the Duet WiFi/Ethernet and Duet 3 have backup watchdog timers too, and we use both watchdogs in the firmware.

It's different when using single board computers to control safety systems, because they generally do not include watchdog timer hardware.

Nevertheless, I am prepared to add a charge pump output facility to the firmware if it would add significant safety.

[A Former User]

@bearer said in charge pump:

, the first seems to come to a full stop while the acceleration/jerk settings are

does not work like that ... you are in "unknown position" so you have no clue when you need to start decelerating, you just hit a switch out of nowhere and you need to stop, and you are moving 200kg for e.g. .. you need 5cm to stop all that .. or 10, or 20 .. unless if you are moving slow, and if you need to move few meters that will be too slow.. again for normal CNC work that's irrelevant as you do it by hand but for automatic homing it will not work ...

as for "make sure it's triggered" .. most limit switches on cnc machines work like that the are triggered while axis pass "trough" them

[A Former User]

@dc42 I never had an issue with ARM that system failed and WD did not reboot it but I did have issues with dspic and pic32mx where kaboom happens and wd continues to reset... also never had bit toggle on ARM and seen bit toggle on 16bit pic's, but I believe that's just due to many more years and more projects I used one compared to other..

now, with regards to charge pump, it's a serious question how many installation will use this feature vs what's required (in your time and in resources on the mcu) .. If I'm the only one using it and you need to spend weeks to implement and test it... not worth it .. if whole bunch of ppl see that as useful and/or if it's 10min implementation .. I'd love to have it

[A Former User]

@dc42 said in charge pump:

watchdog timers

potential scenario

• 3 kW heater is on (will be very often)
• EMI kills the SAM (neither are SAM's known to be super reliable nor there's some excessive EMI protection on the duet board) in the way that pin controlling heater is on (again possible)
• there is no watchdog to reset SAM, SAM is dead
• the heater burns the house down

Now look at it from CP perspective

• EMI kills the SAM in the way that pin controlling heater is on
• CP signal is lost (remains high or low) as the code is not running any more
• CP "safety check" circuit kills power to the whole system

Now, since my "safety board" will be pulling temp info using secondary probes this will not happen even without CP but I think the point is rather clear.

[A Former User]

@smece said in charge pump:

my idea is to use 2 limit switches per side + homing sensor one side of each axis, so you run fairly fast till you hit first switch (~20cm from the edge) then you run slow till you home to optic or piezo

thats what i was referring to, the additional switch will with the current firmware and G1 H1 moves will still come to a hard stop before continuing the next motion even if the next motion it is in the same direction as the one that just stopped. So another solution will be needed, which was the whole point I was trying to make.

normally the soft limits will take care of it, and you can override the unkown state to jog manually but odds are that one time, it'll register two clicks/taps/detens/whatnot and move just that little further than you had planned just a tad to fast. it seems convenient to have soft stops, homing switches that can over travel and hard/e-stops for a machine of a given size - which, as far as i know, is not currently possible. which may or may not be a factor given the initial safety concern.