Advanced Search

PhillC54.
This is an interesting aproach, basically we are muxing the THCAD input, may be some processing power can be saved using only one encoder.
I re-draw your schematic just to make it more readable, I think this will require some changes to PlasmaC componet.
 

What resistor value would you use between positive of the isolated power supply and the positive input of the THCAD ?

Get the Mesa 7i85, without the S.
And THCAD5 or 10 and 2 of 1MOhm/2W resistors, it is most probably a HF/HV pilot start plasma, and 300 is not recomended for those, although i am sure it works, i have several of those in daily use.
For power supplies, 5V and 24V, both at 5A should do just fine, MeanWell or Delta preferably.

Okay so im putting together a parts list to get started with this build. I put power to the driver box, tripped the contactor with a screw driver and a green light comes on the power board and fan runs. im not sure what else I could do to test it besides connecting the burny 10 back up.
So far in my parts list I have

7I83 Analog output/ analog servo interface
7I85S 4 Channel encoder, 8 differential output 1 channel Serial RS-422 interface
THCAD-300 High isolation A-D accessory (Go to replacement: THCAD2)
7I96S STEP/IO Step & dir plus I/O card

I am going to assume that I can hook straight up to the raw arc voltage of the hypertherm ht2000 with the thcad-300. Is there any advantage to a voltage divider board other then the potential risk of electrical shock? Will I need a power supply to go along with these boards? do you have any recommendations for a reliable one on my previous build I used a cheapo china one and the fan stopped working a while ago.

Hey everyone.

I'm documenting my journey to control a CHC-200F (Capacitive Height Controller) as a Torch Height Controller.

CHC-200F is superior to CHC-200E as the "F" has faster processing and also provides a probe output signal.

These systems are made for use with a DC motor in the torch : which LCNC doesnt.

They communicate to the motor with a PWM signal, which overrides the controller's PWM to provide a height correction.

 

The PWM signal provided is 10V with 9 to 18 KHZ frequency. Which can be read by either the Mesa Encoder input with the proper voltage scaling.

Unlike the arc voltage, which the THCAD converts into an encoder signal, the PWM signal will have a polarity so it will have scaled and offsetted..
It will also have a different "meaning" as the encoder in the THCAD, so it will have to be 'read' in a different way.

Has anyone used mesa systems to read PWM?

Is it more suitable to read it with a THCAD?

PS: Im guessing I could also use the polarity of PWM signal to generate two inputs: Move Torch Up & Move Torch Down, and use QTPLASMAC in Mode 2 (Up/down signals). But this wouldn't provide such a fast thc response as the "arc voltage" does.

This post will be advanced as more progress is made.
 

Yes, across the THCAD input side.

I would put at least two of those 5K resistors in parallel, in parallel with the input of THCAD.

Same subject has been answered on 2 other topics with similar tittle.

No need for all that, just add a resistor to THCAD input to raise the required current for triggering.
What voltage is ohmic using?

So your recommending the mesa 7i96s a 7i85 and a 7i83 and THCAD and I could use the stock motors see if they work with this combonation of cards then upgrade down the line if I decide I want better performance. Would this combo of cards support large servo motors and offer great motion control? I included a photo below of the rails turns out I actually have enough to make a 50 foot long cnc. I don't think I will ever need to cut 10 sheets In one go but i was thinking of making 25 foot a water table and keep the other 25 foot to plasma cut beams and maybe a large rotory axis. May aswell set it up am I right? 

First picture, the black servo positioning something or another is what we today call THC, and all that (but much faster) today fits in half a cigarette box! I would get rid of this so fast....
The attached picture with 4 boards, the left one is the power supply for the next 3, those 3 are the servo drives with lots of electronics, so i would really try to save this, do not worry about the broken encoder connectors, encoders should now be wired to Mesa board.
The box with PLC, i would also get rid of this, fast, all that is now done in software and through a Mesa board.
I would suggest getting a Mesa 7i96S with 7i85 and 7i83 and THCAD for now as this will be good for analog (existing drives) and new drives with analog or step/dir controls.
There are cheaper combos or single board solutions like Mesa 7i97T that everything for analog servos and encoder feedback, or 7i92TM with 7i77 that is the same things functionally.
For new dives with no feedback to LinuxCNC, 7i96S should be enough and you can add 7i85 for encoder feedback at any time later, or single board solution with encoder feedback = Mesa 7i95

P value for stepper systems should never be changed, and it depends only on servo period timing, so for a servo period of 1000000 (1 million) it always should be 1000.
Servo period should also never be changed, except in some situations, like when using torque mode servo systems that benefit from faster iteration, or when using a PC with very bad latency. And whenever servo period is changed, so should the PID values.
The math there is 1/servo period in nano seconds, so for
1000000 servo period = 1000 P value
500000 servo period = 2000 P value
2000000 servo period = 500 P value
That is all for steppers in position mode, for servos and steppers with encoder feedback to LinuxCNC those values must be tuned.

Pncconf initially sets the P value for stepgens to 1/servo_period in seconds
(so 1000 for a 1 ms servo thread)

The physical meaning of this is that any position error (due to differences
between LinuxCNCs and the FPGA card clock, jitter, and the time
between reading the stepgen position and updating the velocity register)
is corrected by the next thread invocation.

A P value higher than 1/servo_period will overcorrect, and a a value higher
than 2/servo_period will result in oscillations.



 

Great news! It works now!, that P value was definitely the issue. I set my P value to 1000 as advised and the machine operate perfectly now!,

Is the P value something i calculate based on my jitter servo value or is that just a fixed value of 1000? 

For example, if my servo thread jitter reads 15586, would that mean my P term should be 15.586? (15586 divided by 1000?) 


I appreciate all you guys help so much , you are amazing and i apologize for being a noob. I'm doing my best to learn and im getting better everyday, thank you all so much!

Now i have to get a few things polished up and tune it all in. I am so excited!!

I'd love to know why the PNFconfig generates that as the P value? All the DIY's i followed never mentioned that P value was something i had to modify/tune.

OK the reason for the stepgen instability is the the P terms are all set to 10000
but should be 1000 for a 1 ms servo thread.