charge pump
-
@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
-
@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
-
@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..
-
@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?
-
@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.
-
@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/ -
@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 
) -
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.
-
@DaBit, this is the European competitor. More expensive and potentially better quality(?). http://www.elidefire.eu.com/en/the-product
-
@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
-
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.
-
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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
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.
-
I suspect that most devices that provide a charge pump output at above 500Hz are either generating it in hardware, or are simple devices running a very simple software loop. Generating charge pump signals at high frequencies is not very practical for a complex software system running RTOS. The tick interrupt frequency could be increased by a small factor to generate a charge pump frequency of 1kHz or a little higher, but much more would use up too much CPU time.
-
@bearer said in charge pump:
I started the (happy!) new year with a somewhat scientific experiment.
Do you know how fast it detects that the signal stoped? (e.g. feed 100KHz, 50%, then set a fixed input voltage and measure time to shutdown signal).
-
@zapta said in charge pump:
@bearer said in charge pump:
I started the (happy!) new year with a somewhat scientific experiment.
Do you know how fast it detects that the signal stoped? (e.g. feed 100KHz, 50%, then set a fixed input voltage and measure time to shutdown signal).
faster than i could observe without a scope, same result if signal went over or under about 3/97% duty cycle or below about 250hz.
-
@dc42 said in charge pump:
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 charge pump signal indicating that at least the heater control processes are sane is still high on my wishlist, and I would not mind an erratic signal. Easy to cope with that in chargepump signal processing circuitry, and with a 3D printer I absolutely don't need subsecond reaction times.
Should I do an official feature request somewhere?
-
@DaBit said in charge pump:
@dc42 said in charge pump:
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 charge pump signal indicating that at least the heater control processes are sane is still high on my wishlist, and I would not mind an erratic signal. Easy to cope with that in chargepump signal processing circuitry, and with a 3D printer I absolutely don't need subsecond reaction times.
Should I do an official feature request somewhere?
The Heat process runs at intervals of 250ms, so any signal it generates would either comprise short pulses at 250ms intervals, or a 2Hz square wave.
There is already a software watchdog in the tick interrupt handler to check that the heat task is active. The tick interrupt handler is monitored by the hardware watchdog.
-
A 2Hz signal would require an approximately 0,2Hz time constant for the CP detection circuitry. Completely acceptable for me. 0,02Hz would be acceptable too. But a 2Hz signal is not very useable with other off the shelf hardware unfortunately.
I don't really care where the CP signal is generated and what it's actual frequency is, as long as it is a reasonable reflection of software health state. The tick interrupt handler might be the most convenient place and the most conventient frequency. If it ever proves to be ineffective it can always be improved.
