charge pump

A Former User

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.

A Former User

As far as EMI for the Duet goes, the intention is to rely on external housing for this, where you would also terminate shielded wires as the board does not have pins for shields on each i/o.

dc42

@smece said in charge pump:

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

Yes, that is the "sudden catastrophic failure" of the MCU that I mentioned.

What output frequency would be suitable? 500Hz perhaps?

A Former User

@dc42 said in charge pump:

500Hz perhaps?

https://www.geckodrive.com/support/step-drives/g540-initial-setup-guide.html

The G540 will not come out of FAULT mode unless there is a charge pump (watchdog timer) signal present. The charge pump sends a 10kHz signal to the G540 on pin 16, and must be enabled for the indicator LED to come out of FAULT mode.

I do recall reading elsewhere it was less picky and 5-50kHz should be fine given a 50% duty cycle. (Edit: I have one of those to test with btw)

DaBit

I am also coming from the CNC world, using charge pumps to trigger the main power relay which switches the incoming threephase power, and also the servo drive enables are implemented as chargepumps. In my case the chargepump circuits are usually the simplest possible ones consisting of a transistor, resistor, capacitor and diode.

500Hz would be plenty. Easy to adjust RC time constants to the frequency at hand, but too low makes reaction time sluggish and makes the circuit susceptible for AC line noise.
I would prefer a line toggling when the main processing loop has verified that all subtasks are running fine over a subtask that simply puts out a squarewave, even if this means an irregular frequency and dutycycle. With a preemptive RTOS two tasks can be in deadlock while the chargepump task still keeps running, an undesirable situation.

A Former User

@bearer said in charge pump:

G1 H1 moves will still come to a hard stop

I was not thinking about it too much TBH but if we have variables in gcode something like

move 10cm
test switch1
if triggered goto 5
goto 1.
G1 H1 to switch2 at crawl speed

now, as I mentioned before, never used variables in gcode nor have a clue if something like that will be possible... time will tell .. also never made this big cnc's with auto-homing so..

but even with "hard stop", the system will "try to stop", it will of course not stop and will go trough the stop, the idea is to not hit a hard limit (end of rail) but the only force is on the motor and spindle ..

@dc42 how does the G0H# move handles endstop now? the move start by accelerating, so we have ramp up part of the trapezoid, and then endstop is triggered, do you ramp down or you just stop stepping ?

A Former User

@dc42 said in charge pump:

500Hz perhaps

for me 500Hz is enough, dunno how "standard" it is, most of the CP signals I dealt in the past are around 10kHz and below 50% DC but it's really a super simple "receiver" circuit so 500Hz is more then ok for me.. maybe someone else interested in functionality can chime in too

A Former User

@bearer said in charge pump:

The G540 will

bunch of drivers that use CP for enable use that "around 10kHz" signal. mach3 is for e.g. pushing 12.5kHz iirc, linuxCNC also something around 12kHz.. need to check datasheet for these xinje drivers I use, attm I don't use enable signal on them at all..

now, I myself, plan to use this signal on my own "security board" so I'll read whatever is there, 500Hz is plenty .. the only important thing is consistency .. as in order to have "simple" reader the frequency and duty cycle need to be somehow consistent as the "reader" is just charging a capacitor .. and it is hard to size the input resistor and bleader resistor if the DC and freq. span too much

A Former User

@dc42 btw, I'm still very far from this machine, the mechanics and base electronics (encoders, drivers..) should be done around september 2020, and then I need to add "brains" to it .. I asked about charge pump "now" 'cause I was sending some pcb's to china to be made and shipped here before prc ny so I noticed duet has no charge pump..

zapta

@smece said in charge pump:

it is hard to size the input resistor and bleader resistor if the DC and freq. span too much

How soon after the signal stops do you want to shutdown?

A Former User

@zapta I'm targeting "under 1sec", that's why 500Hz is for me enough... but maybe someone want to use that signal as enable for drivers or for some other standardize equipment and 500Hz is maybe not enough for them, hence I mentioned that others should chime in if interested.. for me personally and the way I will be using it, 100Hz or more is enough.

zapta

@smece, < 1sec sounds reasonable. This is to detect that something is wrong with the duet and it's can't be trusted. However, in most cases, the duet itself will detect and signal the error, so you may want to have a fast path for that signal and immediate shutdown (e.g. if heater behavior diverge from PID model).

Another option is to leave a few of these around the printer http://www.afofireballs.com/

A Former User

@zapta the "full story" is tad complex but there will be a small house dedicated to my "dirty hobbies" and that's all in the renovating phase attm so there will be a fire suppression system built in with small burstable capsules and the whole chabang there .. so no need for the afo balls .. they are interesting for smaller printers in enclosure.. this external safety board is just another layer of security, there always need to be more layers, wrt CP this is just in case MCU meltdown (which is rather rare, and in my experience does not happens to ARM's at all )

DaBit

As said before, too low a frequency is not desirable; a charge pump circuit should not react to AC line frequencies, you want teh CP line frequency at least a couple of octaves above that so one can separate it with the 6dB/oct rolloff of a single RC.

@zapta: Love those AFO fireballs, thanks for the tip. I think I buy a few of them and put them inside my machines and above the workbench.

zapta

@DaBit, this is the European competitor. More expensive and potentially better quality(?). http://www.elidefire.eu.com/en/the-product

A Former User

@zapta the specification state that for electrical and gas/liquid fire it's monitoring only .. not sure how it will work for 3d printers ... I'd still prefer to cut the power

A Former User

Regarding the frequency, I started the (happy!) new year with a somewhat scientific experiment.

I've hooked up the signal generator to the charge pump input of the Gecko G540, and had a look at what its happy with or not.

At 50% duty cycle it'll accept from 600Hz and past 100kHz (into Mhz in fact but stopped taking notes at 100kHz).
At 25% and 75% the range narrowed to 750Hz on the lower end.
At 12.5% and 87.5% same as 25%.
At 6.25% and 93.75% further narrowing to about 1khz on the lower end.

No perceived difference in square, saw, sine or even noise output functions. Its worth noting that once started at say 600Hz/50% it will not fault until the frequency drops below 250Hz or the duty cycle drops below 3%. Hope dc42 finds the data, even if just one datapoint, useful.

dc42

There are two easy outputs that could be provided. One is a square wave at 500Hz, generated in the tick interrupt service routine. The other is a lower frequency, more erratic signal generated by the main task loop. The interval between state changes could rise as high as 200ms when writing to SD card.

A Former User

As i said, I only have the one driver with an charge pump input, but that test indicates it'll either be primarily usefull for a DIY receiver or commercial stuff with even grater tolerances to what seems to be the ideal frequency around 10kHz for the CNC crowd.

But I'll be happy to test it as is ofc.