charge pump
-
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 possiblyG38.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:)
-
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?
-
@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
-
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.
-
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.
-
@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
-
@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
-
@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.
-
@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.
-
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.
-
@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?
-
@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)
-
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. -
@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 ?
-
@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/