Hello,
had the same thing with this ePid fault.

i can see you are using CSLAB as well.

here the original answer from CSLAB as i went into this ePid Thing:

--- This fault can be activated by:
---  Bad Mach3 version. Bersions newer that 03.043.045 of Mach3 can cause ePID fault.
--- We recommend to use versions of Mach3 03.043.022 to 03.043.044. We always use 03.043.022 version as it's the most reliable in our opinion.

regards Tom

PS i "downgraded" to 03.043.022 and the ePid Thing is gone

Thanks, interesting, would be great to know what they did that an upgrade broke but i guess we'll never find out now.

I have the knee moving under power now, it was my fault for wiring the encoder to one channel and the analogue out to another channel

Its not tuned right yet as it oscillates after it stops when homing.

At least we have motion now.

Way to go Dave!


Mike

Yes, i was pleased i sorted it - hate sleeping on a problem.

Its homing ok with the index pulse too.

Need to sort out soft limits, what sort of speed to limit it to, keyboard shortcut keys and so on.

Hi Dave,
If you are driving the factory open bevel gears with the servo I would stay on the conservative side. Since it is only going to Home at the beginning and then just provide tool offsets it doesn't have to go 800 ipm!!! My guess that even 25 ipm will be tolerable and won't hurt anything. Typically on a standard keyboard I would use page up and down for the A axis and so I would suggest that insert and delete or home and end would work. Hopefully they aren't critical to the working of Mach.

Mike

Ok, great its set on 500mm/min so i can go a little more if wanted i guess, it seems ok though at that speed.

I'm using a stainless kiosk keyboard which has a lot of keys missing (including all the F buttons ) I'll see what there is.

I only use the "F" buttons when I am really upset! ROFLMAO
Sorry couldn't resist.

Mike

LOL

Re the coordinates to use for knee moves?

My original idea was to have the C(knee) axis zeroed along with the Z axis so that when i use my Haimer probe to set work coordinates, the C and Z will both be reading zero, then when the next tool is called the macro can simply send the difference between my probe height and the tool height to the knee axis C.

Now, a learned friend has suggested a safer option is to use machine coordinates for the knee.

So, if its in machine coordinates, when i set the work zero ref (Z), the knee may be reading -250 or somewhere like that, now unless i get jiggy with variables and store the knee machine DRO when i press Z zero, how will i calculate the amount to move the knee upon tool change??

I may just not have seen the light yet but don’t know:)

It would certainly be safer to use machine coords of course.

IIRC variables are system wide so i can set one in the Z Zero call and read it later in the M6 macro's ??

Ok, so i have a general dislike of going near variables - you have little idea of which one is free and i don't like cherry-picking a number just in case its used elsewhere and causes big trouble

So, my next idea to enable me to use machine coords for the knee is this...

Hide a user DRO on my screen somewhere,
Zero this DRO upon Mach loading,
When i press "Set Z Zero" it copies the value of OEMDRO(88) (C axis machine coords) into the hidden DRO - this is now my reference value for all TL calculations,
In my M6Start I can read the hidden DRO, use the value to calculate a move based on the difference between my probe and tool,
Make the move in G53 on the C axis

I'm guessing a test/abort/message will need going in the M6start to abort if the hidden DRO is zero i.e. Z is not set or a rapid dent of the knee could occur if a tool change is manually called etc.

Sound like a workable idea?