Dc servo motor control

My rails are good for parallel but I was worried about diagonal measurement however now this is hard to measure as I have bed in place. When squaring the gantry I used the original esab sensors and did not move pickups. using a 3000x3000mm square on the table and measuring the diagonals I needed only 0.7mm adjustment on one side for squaring, however I dont know how the old controller was set for squaring.

I did not see the machine where it was last installed, also there was some damage to the cable tray on the gantry from moving the machine. I decided to loosen gantry bolts and home the machine. Now the machine does not move/jolt when I hit the e-stop, and  can restart after an estop ok. machine is cutting square also. If move the gantry by hand when e-stopped however and try to restart I still get the following error, this is understandable as the gantry is 4 meters wide and each end carriage is heavy, the machine is not so rigid as to keep within small tolerance side to side when motors are not under power, perhaps I should open up FERROR settings a little on this axis.

You should check the encoders, the tend to get rusted, the slotted wheel inside the encoder, that is.
Had to change 2 of them on one of the Esab's.

Sounds great you have it sorted. Surely you don't make a habit of moving a gantry end by hand on a machine that size?
Do you need to worry about it further? 
If you get a following error during estop just think of it as the machine is telling you its out of alignment

Tommy,  at this stage I do not think there is anything wrong with the system, it does not seem to matter where I stop. I put a larger number in for MIN ERRROR value for both motors on the tandem axis and now I can push the gantry during estop and can reset again ok afterwards. My understanding is that the FERROR is acceptable value of deviation during rapids and MIN ERROR is the acceptable value during slower moves and the Deadband is the value that when that close the controller will no longer try to correct the motor position. 

If this is the case then I do have to allow a certain value of MIN ERROR as the gantry is not rigid enough over 4 meters to retain very small tolerances when motors are not under power. So moving axis with unenabled motors can cause enough difference between the 2 encoders to cause following error and not allow reset if MIN ERROR is too small. Another way around this would be to program in a small delay to allow motor to reposition axis on reset before allowing error.

Would I be right to say that using a larger MIN ERROR value wont actually effect the accuracy of the machine (correct scaling, tuning and deadband values will effect the accuracy), It will just allow for more error before fault occurs? Im using 4mm MIN ERROR and 25mm FERROR on the tandem axis and it is ok now.

One thing I  will need to check is that the eccentric roller follower bearings to set rack and pinion engagement are set exactly the same on both sides (I just done them until there was no slap), with this check maybe I could bring MIN ERROR down slightly, but I wont ever be able to get it much smaller on this gantry setup as it is simply not rigid enough. If gantry is pushed from one side there is the factor also of the gantry weight, the bearings on the carraiges, the condition of the rails and even the drag of the little dirt scrapers on the rails. 

Rod, I dont really be pushing the gantry around usually when not enabled in proper use, I just use this as to make a comparison to an estop situation where which the machine was in motion when the E-stop was pressed, as under that condition the gantry could be moving with disabled motors. On this machine there are trip wire e-stops and e-stop to detect large items on the gantry rails so it could happen easily. But I guess in the event of a real E-stop the both motors lose power at the same time so in reality it is less likely to cause much deviation between the 2 tandem motors than pushing from one side as this is an uneven force.

I have been using the machine now and I am very happy with it! I would like to get using the cut recovery feature however I have not needed them yet ( which is only  good thing!). The height control has been working well just using the Hypertherm suggested feeds and voltages (hypro torch and silverplus electrodes, 200 amp oxygen). The HT2000 unit has also been operating very well, I thought there were problems with it when I had the old control on as it often missed arc starts, however it has not missed yet on the linux setup. There were "arc hold" signal wires on the comms cable which I no longer use, perhaps something was at fault in the old control causing it to hold onto the "arc hold" signal. I did however go through my table and plasma grounding when I was wiring in the new control box and improved the grounding by quite a bit so perhaps that has been more the issue. I will get some videos up of the machine over the next few weeks.

 

If you can run the machine all 4 meters back and forth without errors, that rules out the encoders, so they are good.
Seems you got it figured out, soooo .... where are the sparks ?

I'd have to think this through a bit but it might be possible to write a custom component that sensed when the motors were not powered up and set commanded position to equal feedback position. joint.N.amp-enable-out might work for the sense signal. BUt a relay on the Power to the drive that set an input might be better.

That would totally eliminate the issue because if the drive was not "armed" for motion, the encoder becomes the master of motion.

There is a component that uses internal homing features of some ethercat drives that does this when the motors are moving from outside of linuxcnc control. I am trying to rewrite it to be a custom homing module.