Dc servo motor control

Some more work done, just waiting on a new 7i77 as I ruined 2 outputs, for some reason it will not let me use the 6th analogue output, it was still spare, the pnc config added a new line in the hal file which did not appear with any of the other AN outputs, and whenni remove it it still does not work. Anyway new 7i77 should be here soon.

I have ended up going for a float switch, the ballscrew of the Z-axis drops after away from the carriage after the torch rest on the sheet, so I used it for sensor pickup.
 

New box, screen installed
 

Need a Shorter cable to avoid coiling or an adapter to put the 7i92 onto the 7i77 as Tommy suggested. I used a supply separate to the esab 24vdc for I/O, I used a relay to control servo enable. All other I/O is separate to esab dc supply. This was maybe not needed.
 

Z axis box with drive, old connectors on top were reused for float and collision sensors. Z up and z down are just original switches. 

The only additions to the power box are the 48vdc psu at the top for z axis motor and the termination conectors and ss relays on the bottom right. A cleaner/easier/better way to do this would have been if I could source a 120vdc drive and use the spare drive power output from the esab card, but this works fine and I had a 48v psu spare.
 

 

Thanks Tommy, I have now got output 6 working, when looking the hal file it had actually generated 7i77.0.pinena, I just added the letter "s" and it worked.

So far no problems on arc starts. I am using mode 1 to operate the machine, using the input from Hypertherm for arc ok. At the end of cuts I get error "valid arc lost" I have changed debounce from 5 to 50 for the arc ok input however the error remains.

I did try mode 0 however the machine began to move before arc began even though no arc voltage was showing and I had set min to 60. I think it is best for this machine to use mode 1 anyway for preflow gases.

Ah I have made a mistake, I had changed the arc ok, I have now found the arc lost one, it was set to zero, so I will make it half a second and give it a go. I think this could have been the issue, especially as I was testing at 200 amps but in thin steel, so at the end of cut arc may actually be lost as wide kerf and big amps has blown away material slightly before the cut ends.

That has helped, I no longer get the error at the end of cuts. The machine was used to do some cutting yesterday and preformed well, the THCad THC working very well, the only problem I have now is that if I E-stop the machine I get a following error. To re enable the machine I have to close and reopen linuxcnc. The gantry does move slightly when servos are disabled, so I think at rest the machine is very slightly out of square (I squared machine using dual proximity switches, using a 3000mmx3000mm square and adjusting the offsets until the Diagonal measurements were the same). I may need to loosen the gantry top beam bolts when the machine is squared to remove any tension when in operation, even for good practice, however this still will not fix my problem if the gantry somehow gets moved when servos are not enabled.

I did see a post where the time delay function was used for a different job, perhaps this would be able to be used. I should say I am using the x enable signal to enable all axis on my machine, I tried the "machine is enabled"  output in PNCconf and it did not work.

you are not getting an error finishing read with your following error?
So it is from encoder movement?

Rod, there is no read error, just a following error, yes i think it is from encoder movement after drive has been disabled. The error actually doesnt appear until I hit the "power" button in linuxcnc after resetting the e-stop, i sent you a video of it there on fb.

I'm not very experienced with servos and encoders.
But one possibility is that when the motors are disabled, the gantry springs back into position enough to cause movement sensed by the encoders without a corresponding  position command. If this movement exceeds your following error settings in your ini file, it would cause that.

Perhaps you could measure the movement on each side by using a dial indicator set up before you hit estop. Then you could adjust the HOME_OFFSETs so the gantry was in a relaxed state to see if the error goes away which would confirm the theory.