Advanced Search

I found the mistake

pin 21 on the mesa should be no connection 

and the agrnd in the driver should be connected to ground

working like a charm, I just need to replace the resistor with slightly smaller like .3 kohms. I started with slightly larger resistor to avoid getting more than 10vdc to the motor driver

sorry for such non-adding value posts. it is uncharted road for me.

Good day

Philip

Try with

instead of
 

[edit]
with the above I get this output:

MarkoPolo wrote:

Hi Cmorley

I don't know if you plan to implement the layout in qtdrahon_hd
the same as in qtdragon. If so, I have a modified file, ready to use.

 

Pushed to master.
Thank you!

this is how I wired. 

I also connected pin 6 (servo motor enable to common , not shown in the diagram)of the driver 

 


 

I ran the servo motor in speed mode with potentio-meter. It ran fine.
but when I connected the servo driver to the mesa 7i96s, and configured the machine via pcconf wizard, I could not get the servo to run. The servo is running at low rpm but not responding to the axis spindle user interface. No voltage detected across pin 21 and 23 of  the mesa TB2

The x,y,z stepper motors running fine via jogging in axis interface.

Not interrested at this time in bi-directional operation. 

below find the pcconfig relevant pages, I will also include in a second post the connection diagram and spindle driver manual

Good day

Philip

 

Yes, best performance would be from cascaded PID loops (and inner velocity loop and outer position loop)
but its probably possible to improve the performance considerable with tuning..

1. To reduce the static error you can add more I term

2. To improve overall performance of a torque mode loop, I would decrease the servo thread period
to say 500 or even 250 usec (2x or 4x higher rates) This will allow higher stable P and D term gain
and correspondingly lower following error.



 

Hello LinuxCNC

This is my first post and I am a novice with LCNC. I bought this machine already converted with DC brush servos and incremental encoders and have been diagnosing the following issue. Thank you in advance I'm really stuck on this one.

Each axis will not move to the full commanded position, read on the DRO. If I do G01 X2 the DRO will move to 1.9980. If I do another absolute move to X3 the DRO will then read 2.9980. This 2 thou offset drops to 1 thou if I increase Proportional gain from 50 to 80. Going higher than 100 or 200 makes the joint rapidly accelerate and terminate with a joint following error. Also, when I home the machine it goes to X -0.0018 Y 0.0017 z 0.0006 .

Encoder counts are coming in fine at 50,000/inch, and table movement matches one inch.

Similar on the A axis, it stops roughly 1 degree short of command.

Could these be PID issues? The servo drives are in torque mode I believe (Copley 4122). Now, is LCNC in velocity mode if I only have one PID loop per axis? Does torque mode require 2 PID loops? and how would that be set up in LCNC? 

Is there anything else that would cause this? I'm hoping the answer isn't to buy tachometers and velocity drives.

I've attached the ini and hal files as a start, but if you need anything else please let me know. 

Thank you,

Benchman XT CNC Mill
Litton Clifton Precision C23-L servos
Copley 4122 drives

SInce there haven't been any replies I'm guessing there aren't a lot of people using EoE with LinuxCNC. It appears there could be an issue either in linuxcnc-ethercat or etherlab's master as there is another thread where PDO configuration doesn't work properly with EoE enabled in the etherlab master.

forum.linuxcnc.org/ethercat/51505-new-hardware-trouble

I'm using xfce and I was actually jogging with the mouse and not the keyboard so I'm not sure the xset would make a difference unless the mouse in the axis interface is just emulating keypress.  Not sure if this could be related but I've noticed that on G0/G1 moves it will overshoot by a few hundredths of a mm and then come back to the requested position, ie G0 X100 goes to say 100.03 and then comes back to 100.  I'm not sure if the continuous jogging is done by sending small movement commands but if it went backward at the one of one then maybe it could cause that.  Testing it in the drive software and Twincat neither overrun and stop on the position exactly.

I would add as much D term as possible until you reach instability
Have you added FF2?  (the FF2 value depends on the system inertia)
 

I am unsure what GUI you are using (perhaps it doesnt matter), but this sounds like an autorepeat issue.

To test if it is, open a terminal window, and enter the following command:

Launch LinuxCNC and jog around. If the problem goes away, that's the issue and we can come up with a more permanent solution.

To turn autorepeat back on:

So, I was checking halscope and modded the "P" value higher - which gave less error. Then i found that It was running off more frequently. So, ive had too high a "P" value. The reason for this really is when I've looked up pid tuning of 8i20 cards you've reccomended setting as high a D value as is stable, but there's no range stated, - is 3 a high value? Is 500 a high value? I don't seem to get good position holding with a high d value as P generally ends up around 185, which you have said before is pretty much saturated.
I'm running a high thread rate 225000 off the top of my head.

Maybe post your toolchange sub also

I agree with spumco, run in terminal so the debug messages show the failure point. Probably something simple I had 0 where an o word should have been that chased for 2 days troubleshooting.. probably started at it 50 times and that was with debug on telling me where the problem was

i suspect if i am reading the hal pin with FlexGUI and with a M66, it may be the cause of the hang. reaching here, as i can't find any other cause...
will continue testing tomorrow...