Welcome to LinuxCNC.org

i have changed that now but still the same and im not using a z axis

i'm having problem trying to replicate the error here .. is this a new install or update ? i am of the opinion that somethings screwed up
on install or picking up old settings or scripts or even dependancys , perhaps Arceye may be able to point to the right direction ...

was this installed from live cd ?

Unfortunately I have no experience with these boards or what pncconf generates for them.

All I can offer is that these errors

Debug file information:
Can not find -sec MOT -var MOT -num 1
Can not find -sec IO -var IO -num 1
Can not find -sec LINUXCNC -var NML_FILE -num 1
Can not find -sec EMC -var NML_FILE -num 1

seem to relate to parsing of the .INI file not finding variables it expects at the various headings.

This one is strange Can not find -sec EMC -var NML_FILE -num 1
because if the line was not commented out LinuxCNC would throw multiple errors with any version >= 2.4

The second set of errors are tk/python errors, but also seem to relate to problems with the .ini file, either parsing it or even just finding it
set ininamearray($axisentry)

Don't know if this helps at all.

regards

At first I upgraded and had the same pic not working issues and then a clean install from the live cd with the same issues it there a problem with the live cd also I cannot see it but the USB install stick I made this time round was made on Ubuntu it's self instead of on windows like I normally do I will try a few different ways of install

Thanks

is it just me or is there an issue with the live cd i can do a fresh install, open pnc, set firmware to svst8_4 change encoders to 4 change pwm gens to 4 and step to 0

and change the pdm base frequency to 6000000hz (unless thats not 6mhz like it states for the 7i33 card)

and then config the x and y encoders and PDM gens and continue to next page (skipping limits till i can get the open loop tests i have configured them and it makes no difference)

then on to the axis config and the open loop button is greyed out

but if i use the test panel on the mesa config page i can run the servos ok

in the meantime i have been hand coding the hal file from 2.4.x emc to add things as i get sorted i would however prefer to use pncconf

any help would be appreciated am i doing something wrong shall i get ubuntu 10.04lts and install linuxcnc on that insted of the live cd?

many thanks john

it seams if you dont fill in the encoder counts field the open loop test wont work

my apologies my fault tho a notice informing of this may help

sorry for the wasted time on this

Hi there.

We've got a question. Is there any way to determine encoder failure (for example cable cutting).

There are 2 pins for each encoder chanel at 7i33 ex. ENCA and /ENCA. So is there any way to check ENCA xor /ENCA and raise Estop on failure?

Thanks in advance

I believe that encoder channels can be checked with a mulitimeeter or an led you can look up the led method here but I don't think this is what you are asking

I think if the following error is set as it should be the missed encoder counts that would come from a loss of channel the machine will estop anyway as this should I think be enough to trip the following error and stop motion

Here's the problem we've faced:
having lathe we got encoder failure on long rapid move like
G0 Z500 X1
G0 Z0 X0
So we have small travel for X axis that is inside ferror tolerance. Once the encode going down to failure (the A channel has been disconnected), PID become unpredictable and the axis continued moving. (LinuxCNC thinks that axis is held in the current position but the axis was traveling).

So it lead to a crash. Likely nobody was injured (the lathe is quite big and strong).

So we want to be sure that any connection or any wiring problem would not lead to a crash.

It can be done by checking xor of both A and /A every MESA tick. Then we can be sure to eliminate any connection problem.

This can be also be checked with some drive heuristics (encoders fail from broken wires _and_ from internal failure/contamination)

One heuristic is the saturated PID check (if you have some integral term a disconnected encoder will cause a drive runaway and a saturated PID output --> Shutdown)

Another heuristic that works with velocity mode drives (and is faster that the saturated PID check) is to verify that the PID output (scaled in velocity -- this is automatic if the PID loop is normalized that is the output is scaled in machine units/second) is within an error band of the commanded velocity.

The best way is to have 2 encoders...