Advanced Search

Try this:
Remove 1 driver, unplug its motor, and remove the motor socket socket from the chassis.

Examine where the socket leads connect to the driver's PCB.

Thick traces are probably motor winding connections, thinner ones are likely signal/optointerrruptor connections.

Now separate the socket leads for the motor windings from the driver and use an ohmmeter to determine their configuration.

Brushless DC motors are probably 3-phase.
There should be 3 or 4 thick wires.

Buy a single servo drive (can be cheapish).

What are the errors?
 

Note that if you copy/pasted stuff from this earlier post the debounce stuff is actually commented out so you likely wont need it:
forum.linuxcnc.org/10-advanced-configura...n-2-8?start=0#155864

if your scale is that small then it's not really surprising that there is no movement so I would suggest to set change these two lines

To this:

Here are the A asix files   

I need help setting dual Y, X, Z and A axis .  A is rotation.  The config wizard won't set up YY with A axis.  I have a functional XYYZ program that I copied the additional Y axis  ini and hal file components from and added to an XYZA file I was able to configure in config wizard.  Maybe someone can see what I am missing as I get all kinds of errors.  The Dual Y Axis Mill works fine.

thanks in advance for any help.

Routerworks

It captures keyboard buttons for xyz axis in pause state.

This is a cool feature but IMO the use of keyboard keys for jogging is rather unfortunate. There have been several calls to move away from keyboard jogging. Why not use one of the existing hal pins like 'halui.axis.L.minus', 'halui.axis.L.plus' or better yet create dedicated hal pins for jogging while paused.

Hi All
Does anyone have these drives jogging that can try some moves?
What I would like is if you would try some programmed moves back and forth while monitoring the target position (607A), the actual position (6064), the pos-cmd  (60FC), the corresponding joint.X.f-error and show their values after a few (10) moves of whatever distance you can travel back and forth.

My issue is as follows:

I have 4 LC 10 E 1000 amplifier kits with 2500 RPM 17 bit motors, and they are all exhibiting the same following error issue. 
I am running the servos in CSP mode at 1kHZ with LinuxCNC.

The issue I have is that the target position (607A) develops an offset and the actual position (6064) does not become equal. There is a random offset, which seems to grow over time. It can be thousands of counts. The motor actual position (6064) remains correct. The motor is counting correctly. I put a dial gauge at the end of travel, and the actual position (6064) is correct. To compensate for this, I put an integral loop in the machine controller. With this integral loop the machine moves correctly. When the controller software disables the drive power, and re-enables, the offset is gone. I have monitored the pos-cmd (60FC) and it follows the motor actual position (6064), until I disable and re-enable the drive. When I disable and re-enable the drive the pos-cmd (60FC) feedback value does not match either of the other 2 (6064) or (607A) however (6064) does now match (607A). The machine will then move to the correct position without requiring any integral compensation for a period, until the offset re-appears.

The offset between the target position (607A) and the actual position (6064) remains even if I jog the axis slightly, or if I manually force the servo out of position slightly. The servo wants to maintain the offset error. I have tried changing all of the gains to see if there is an effect on the error, and there is none.

Encoder Position Deviation P0B.15, always remains _0000. I would expect it to show the following error.
Position Deviation Counter P0B.53, always remains _0000. I would expect it to show the following error.
Input Position Command Count P0B.13 matches pos-cmd (60FC). It matches even when the target position (607A) and the actual position (6064) are different values.
The last fault shows as P0B.33 == 1, P0B.34 == 952 which is reverse over travel, which was from homing.
Actual motor speed P0B.55 does display values that change and seem correct.

The software version is: P01.50 ==>  03.16

oddwick wrote:

oh and usb 1.1? thats some old stuff from the "plug and pray" days!

yes it is, it has never ever failed me, so i keep it in my "go bag" with all the expensive tools i use in the field, it deserves it.
BTW, disable IPV6 on the PC, there is still no use for it.

Hi all,

Today a new feature is added to the planner.

Jog in pause state.

It captures keyboard buttons for xyz axis in pause state.
This feature should work for every used linuxcnc gui, axis, gmocappy, qtvcp, etc. The whole mickmack.
When resuming the motion, the xy is running back to pause-pos, then the z is running back to pause-pos.

Next feature is tangential knife.
Will do that next time.

Oh wow... I've been racking my brain because of a spelling mistake...

thanks tommy, gonna give that a try. i have some old parts lying around and i think i will stretch some cables and give it a dry run this afternoon out in the shop. when this is done, there will be 4 machines all with mesa cards and if this works out it will make life alot easier with just one station to control all of them. ill post after i run some tests...

oh and usb 1.1? thats some old stuff from the "plug and pray" days!

There should be no Base Period in use for Mesa boars, only if using a parallel port together with them.

Ini file, axis y / joint 2 section still says AXIS Z
Andit is miss spelled, should be COORDINATES

Easy, you have the hardware, connect stuff and test by running some gcode in "air cutting" mode, see if it drops the connection.
As for throughput, i have a very old USB to LAN adapter that i am pretty sure is USB 1.1 and it works fine for Mesa directly connected to it.
I also tested laptop to Mesa through a gigabit switch and had no issues but those were the only things attached to the switch.
And i would venture a guess that any access point will fail miserably and drop connections even if PC and Mesa are using LAN, not WiFi, at any point any request from WiFi goes to PC or Mesa and vice versa.

and the result of