Full featured Serial Communications

[simpson36]

I have been looking at a bunch of different servo drives recently and it seems most like to talk thru a serial port.

Mach has a simple function to dump some characters out a standard serial port and also a very 'bare metal' method of talking byte by byte to a non standard port.

There may well be more stuff available within Mach that is not documented, or that I just have not found yet, but a bi-directional communucation structure would allow clever script writers to utilize the monitoring/reporting/control capabilities that most of these newer drives seem to have, and take a big step toward a true closed loop system for Mach.. 

[vmax549]

I don't think Mach will ever be able to CLOSE the loop by itself. It takes realtime hardware to do that. Mach  is not realtime it runs a buffered system.

That said all modern servo drive close the loop at the drive and steppers can't really use it.  BUT it is possible to run a closed loop stepper drive but it will not be any better than a standard one other than it can tell IF it has lost steps (inside of a bandwidth) and signal MACH to stop Same as a servo.

The need for closed loop at the control was from the days of the DUMB analog drives thta could not do the PID and it was done at the controller where there was realtime hardware to do the job.

Just a thought, (;-) TP

[NosmoKing]

The need for closed loop at the control was from the days of the DUMB analog drives thta could not do the PID and it was done at the controller where there was realtime hardware to do the job.

I prefer to call them 'non-intelligent' :-)
Which is what you would use still if the Galil plugin were used for example.
This brings the advantages of Electronic gearing, electronic Cam, feed/rev and encoder synchronized threading etc.
Nosmo

[simpson36]

I wasn't thinking so much of Mach being fully inegrated with the loop as I was having some ability to get info from the drives and make decisions based on that info. And also to set certain of the drives parameters from within a program to tailor the performance for the particular task. This really is just an expansion of the tailoring already done in terms of spindle speed, feedrate, depth of cut, etc. Simple examples might be:

1) rather than have the servo drive just stop the parade, it could signal a problem and a macro or brain could query the drive as to what the problem was. If, for example the encoder has failed completely then  of course stop the parade, but if the following error has exceeded a certain amount, but has now recovered, then do nothing, but the operator would have some insight into what part if the program was causing the fault and could go back and modify that portion rather than slow the entire production down to avoid a single problem spot.

2) if the following errors are consitently over a precsribed amount, reduce the feedrate.

3) set the faulting and folowing error at the beginning of each program. For close tolerance finishing work, the following error could be set small and for roughing it coudl be set high.

4) I would prefer to see a flashing red light on the screen if I am observing the machine. This would be a great diagnostic and  tuning tool. If the machine is unattended, then the same fault should stop the program. I think this would be a useful function to add.
 
For my current effort, this whole topic has become moot since none of the drives I have tested so far are going to be useable for such a process.

[vmax549]

YEP seen this tried many times, it seems this is the holy grail for hobbiest(;-).

THe servo drive already does most of what you want. It monitors the position AND if it exceeds the following error it faults and creates a stop signal for mach. IF it has a following error but does NOT exceed the limit then it catches up and continues.

THe real problem lies in that MACH cannot resend steps to correct the path. It has already ran the math and applied the motion and sent it to the buffer to be run.  Any corrective action would have to be handled by a motion card that buffered and stored the positional data and kept track of where it actually is compared to where it it suppose to be. Not an easy task as it takes parrallel motion planing to do this, one that tells where it is suppose to be and another that tells where it really is then really another processing a return  path in the event that #2 strays from #1 (;-)

I have seen a machine that could do this. It was about $50million dollars worth and ran 8 dual core processors in parrallel.  AND the end results was not really that impressive. AS it really could not do anything any better than a well set up machine could. It was just redundant. If it saw an error in roughing all was well it could recover. BUT if it saw an error in finish the PART was already toast at this point so it did not matter.

NOW mach can do serial IN/OUT thru modbus standards. AND you can do other serial but you have to do it through a plugin.

My oldes SON( motion ENGINEER) says it best. NEVER try to fix something with software that you SHOULD have fixed with hardware in the first place.  Very true in CNC.

Just a thought, (;-) TP

[vmax549]

One interesting note we tried in the past was to set up a monitor for the spindle RPM and used the programmed verses actuall RPM drop to control the FRO in mach. THAT worked better than we expected. As mach saw  the rpm drop it slowed the feedrate. THe more it dropped that slower the feedrate override.(;-)

ActRPM/Prpm= % of change X FRO ---- sent to the FRO dro (;-)  Poor mans axis PID so to speak. AND that was about the only thing we could find in the buffered controll that mach  could influence to controll the motion after the buffer.

I really worked well BUT it was slow as the Mach update loop is 10hz. (;-) THat will change with M3v4 it goes to 50hz. I have seen it so fast that the displayed data updates was a blur.

DANG now you have me thinking again.

AND don't forget it is possible to have a closed loop STEPPER control with hardware.(;-)

Just a thought, (;-) TP