Since your machines do the same thing over and over again, you don't need to worry about changing positions, velocities and accelerations on-the-fly.
We do this all the time.
Our Bluetooth-linked tablet-based HMI features a feedrate override on-screen. We handle some massive machines, capable of bending 12" diameter. There is a lot happening and a crash is usually expensive. When running a part-shape for the first time, we nurse it through the sequence, speeding-up and slowing down.
Using the integrated sensors, the operator can tilt the tablet to trigger an immediate stop (no decel)
In total, we have 5 different 'stop modes' alone. If the immediate stop happens to overshoot the new commanded position, we have a mode where it will then profile itself backwards.
Yes, our acceleration/decelerations ramps are parabolic.
Thinking out loud (haven't tested this yet): Why be stuck with parametric velocity profiles? Why not give the user the flexibility of drawing a profile on his touchscreen (albeit with some kind of snap-to mechanism)?
The target generator is capable of moving from any initial PVA ( position-velocity-acceleration ) and any final PVA over any time period. It is also capable of moving from any position, gear ration, and gear ration rate of any maaster distance.
Yup, any combination of masters/slaves and the master reference can be either the master's command or the master's actual position. With a dual-loop system, the is also the option of the auxiliary feedback.
Of course there are physical limits but not in the RMC.
Except for the 32bit position range.
Trio Motion do 64bit, mine is selectable 32/64 (I take a slight performance hit with 64bit)
What is perplexing to me is that; I have seen your mind-boggling (to me anyway) math capabilities but I'm just wondering
if it's a case of seeking a mathematical equation to solve every problem whereas a coder would use simple logic?
Example:
On more than one occasion, you brought-up the question of what happens when a trapezoid needs to become a triangle:
The fundamental issue is that the distance_to_accelerate + distance_to_decelerate exceeds the move_distance.
Why not integrate, reducing the command_velocity until we have a fit. In this particular case, I reduce the speed value by 10% for each iteration of the loop:
Code:
sp_e = 1000 'Axis_E command velocity
ac_e = 2000 'Axis_E command acceleration
dc_e = 2000 'Axis_E command deceleration
move_e = 15000 'Axis_E command move
tenpercentsp_e=sp_e*.1
ta_e = sp_e / ac_e 'time to accel
td_e = sp_e / dc_e 'time to decel
da_e = (ta_e * sp_e)/2 'distance to accel
dd_e = (td_e * sp_e)/2 'distance to decel
while (da_e+dd_e)>move_e 'this won't happen in this case because we have a trapezoid
sp_e=sp_e-tenpercentsp_e
ta_e = sp_e / ac_e
td_e = sp_e / dc_e
da_e = (ta_e * sp_e)/2
dd_e = (td_e * sp_e)/2
wend
ds_e = move_e - (da_e + dd_e)
ts_e = ds_e / sp_e
Can you explain the math, calculus, involved in the video above.
Nope. I also don't decorate my own bathroom.
If I have a problem like this to resolve, I farm it out (freelancer.com) for $100
That's what I did when I needed inverse kinematics for my 6-DOF articulated arm. I went to the pub and it was in my email the next morning.
I don't do JAVA but I needed 3d animated renders of my programmed parts (Android), including zoom, rotate etc.
They were delivered the next day for $100
I just demonstrated a simple flying shear. This requires precision.
And then you go on to state that you strip unnecessary code from the RMC PID loops to achieve a mediocre 125usec
It's been a number of years now but the guys who build the Alpha Tube Cut-Off (flying shear, maybe a RMC user?) told me that they wouldn't look at anything other than tach-feedback for velocity control. I would have to believe that 8KHz is easily fast enough.
To achieve 65usec, Galil's "Fast firmware" also ditches functionality such as E-Cam, gearing and dual-loop, etc. and even then, any more than two axes and it's 125usec and it increases from there.
OMRON PMAC boast "fastest in the world, 5-Axes in 25usec". No idea if/what compromises they make.
My alleged performance-limited (8 CPUs @ 250MHz each + 64 smartpins) P2: 6 X dual-loop axes in 2.5usec. This is the benefit of a dedicated CPU, no interrupts/jitter and smartpins instead of a separate FPGA.
For a 64bit position range, the 2.5usec increases to close to 5usec.
We can do this for up to 50 axes.
If the P2 had the pin count, I could have 60 axes and still be 5 times faster than 125usec.
I wouldn't do that though. The P2 is all contained on one tiny plug-in board for <$100. I would go with distributed, using the 4-wire full duplex network for data transfer only and close-the-loops locally.
You wouldn't carry a spare?
Also, we have burn in racks and 3 National Instrutments test machines. Our engineers have made bed of nails jigs so testing can be done in a few minutes.
We also log the data for each piece that gets tested. What do you do?
You have your own spares but what if the customer is remote?
If you find a place where the bean counter agrees to keeping an inventory of costly spares, it's Murphy's law that the first part you need is the one you didn't go for because "oh these never fail".
My concept is dubbed: MTTR-ZH or mean-time-to-repair-zero-hours
I designed the main PCB to be nothing but a carrier for plug-in devices. The end-user is provided a copy of everything needed to replicate the board, should they destroy any tracks.
All of the realtime is handled by the P2 module. For what little it costs, there is 2nd module, loaded with the firmware, stored inside the control's enclosure. The same applies to the PLC/IO expander RP2040 modules...they cost $10 and so backup modules are also stored inside.
Standard industry practice has been followed and everything is isolated/protected so a failure is hardly ever likely to occur but still....
All buffers, such as opto-isolators and balanced-line receivers are included in this "care package".
Maintenance guy has a brainfart and somehow sticks 110v AC on a 24v DC input (I don't know how this happens but it does), pop the unit open and replace the $0.50 opto-coupler. No need to order that proprietary 16-input module that costs hundreds - if you can even get one.
All instructional documentation, schematics, BOM can be found in the Android app. Everything I design now includes embedded Bluetooth and an Android app.
Remote support? The tablet has Teamviewer. I get much more than plots, I get to operate the machine, chat with the client and actually observe the machine, thanks to the tablet's camera.
Ethernet is cool but simply not available for most equipment. Ever dealt with these factory IT clowns? PITA.
A 5-year data-only SIM is like $8 which means that the tablet can also send text messages to report downtime, etc.
The enclosure: Top-hat DIN rail is great...NOT! It's OK if you are the panel-builder, stood at a workbench, merrily clicking components on the rail. But when that panel is installed on the machine, the maintenance guy finds himself lying on the floor or high on a ladder, flashlight between his teeth, struggling to work-on or remove this stuff.
I have embedded neodymium magnets. The unit clings tightly to the backplate but pulls away when required. Opening requires only hands, no pesky screws or other fasteners. Any parts that might need replacing are right inside. Job done.
)
