Advanced Search

2009.
I managed to boot - the issue was "Legacy USB Support" option in BIOS - it was turned off.

With this option turned on - USB storage is emulated as Hard Disk Drive - and I was able to boot.

But now I'm testing jitter - and it's waaay to high.
With LinuxCNC 2.7 - max jitter was 25k.
With LinuxCNC 2.9 - max jitter is 3 million.

I installed RTAI kernel - but it cannot boot at all (it says give up on waiting root device). PREEMPT-RT works fine.

Any ideas?

Drives usually have only optocouplers on the inputs, so chances are low for it to short, higher chances of loosing sensitivity (light output as inside the is an LED and a photodiode).
Much higher chances of interference from the spindle and/or VFD that caused a spike, might even be moisture messing things up.

I'm afraid i've got about the same questions as spumco and then some. I got the cables with the batteries installed today and followed your process, changed the config on each of the drives via the physical buttons and updated the relevant parts of the ini. I hadn't set up homing in any particular way before so i didn't have any of the stuff you commented in the hal file, though i was able to trigger homing and they would reference correctly against the inductive sensors even without any special config in the hal.
It'd seem like when i start linuxCNC the axis start on random positions. I get out of range errors if i try to home as is, and if i jog them into range and home after, i usually get amplifier faults. Am i misunderstanding what you mean by reference run? is there somewhere else in the drive's software where the homing needs to be triggered?

Besides that, my kinematics are the same as yours, with dual Y drives, and i'm wondering how gantry squaring works in this mode.

Edit: Ok, i think i sort of understand now, the config you have commented afterwards, you do need for the initial setup. However, where is request-cia-homing and start-cia-homing coming from? github.com/rodw-au/cia402_homecomp uses different names, not sure if what you're using is equivalent. I'm trying to get the initial config to get the homing done before turning off all the config now.

Also another thing, is that I have changed the stepper driver to a new one as I thought initially that might be the problem.

*possible* that the original is faulty and took down the output. Not prepared to test it on another channel though (:

Firstly made a minor mistake on the numbering i.e. 3rd stepgen therefore stepgen.2

This is a small cnc in my home so pretty clean environment using DM556 drivers.
Scoped it with the driver disconnected and hooked between gnd (first pin) and step+.
Figured that since the dir pin toggled when I jogged the Z up and down, that all programming was connect.
Scope looked fine on stepgen.3 and Z now works on that channel.

Probably, but how old is that PC?

Is it a wireless keyboard? I've had those start that when the battery died.

Hello, I've been running LinuxCNC 2.7 for 8 years now and I've decided to upgrade to LinuxCNC 2.9 because it's a 32bit installation, and software support is no longer a thing, browser is barely working, no modern SSH keys support (cannot use github anymore) - so I decided to upgrade to LinuxCNC 2.9 by doing fresh installation.

The problem is that PC won't boot from USB. I used dd to copy ISO to USB - and it boots on my modern desktop, but it won't boot on that old PC.
Is it because ISO contains only UEFI and not MBR ? What is the solution here?

Todd wrote:

.... so no soft limits

Does this also happen when homed? Meaning, does it ignore soft limits?
-
The only thing similar i recall was/is when a jog key is held pressed then another jog key is pressed => releasing them both would result in machine continuing to move until another jog button is pressed. This was probably a few (maybe two) years back, and only happened on 1 PC. I was busy so i did not have time to do more testing.
Does the same thing happen, or does it happen with a single key?
To stop, does any other key work, or just the jog keys?
Did you test with another keyboard?
-
Old info, well very old, the PC's had in BIOS a setting for "typematic rate settings" where you could set how much a should a key be pressed till it starts repeating, then how fast should those repetitions be, and for how long those should persist.
Have not seen that in PC's for over 20 years probably.

No, not a common fault at all, i am sure i have over 80 Mesa boards (more probably) and none of them ever failed, and they are mostly on industrial machines, and all are in use daily, some are never switched off, for over 10 years. And most are on plasma machines, by far the worst machines for EMI/interference.
What machine is yours?
Did you disconnect the stepper drive when checking with scope?

Failed stepgen outputs are most likely due to a problem with one of the
the output driver chips. For stepgens 0..3 these chips are a 74ACT541 (for the + outputs)
and a 74ACT540 (for the - outputs)

Does the  step3- output work? If not, it may be a deeper hardware issue
(PCB or soldering issues) These kinds of issues are rare.

Bad step/dir outputs caused by driver chip failure  are not rare but usually
traceable to accidental contact  of the step/dir pins to a voltage outside
the 0 to 5V range perhaps during initial wiring.

Probably a lost cause, but just in case ...
Turned on my CNC and the Z axis did not move.
After swapping out the stepper driver found that the stepgen no3 on the mesa was not outputting any step pulses as shown on my oscilloscope. Direction pin was changing as expected.
Changed it to number 4 and all is ok.

Assume just a hardware / output driver issue.
Is this a common fault on these cards. It is at least 5 years old. It lives in a pretty protected environment.

At this point I only need 4 stepper outputs so can live with it as is.

I made a new PWM board to +/-10V.
Now with isolated power supply and the possibility of differential analog output. Now the groundings don't mix
 





ps:I saw one mistake, I forgot to bring out the ground for +-10v
ps: 

Yes. that's correct but looking at the parport driver,
you may be able to do this by inverting the desired
output pin by using the out-invert parameter.

linuxcnc.org/docs/html/hal/parallel-port.html

[This would have the advantage that it would likely  work in reset mode
(which doubles the possible step rate at a given base thread rate)

Would this change in the hal for parallel port pin 2/3 be correct?

loadrt not count=1
addf not.0 base-thread

net xstep stepgen.0.step => parport.0.pin-02-out
net xstep => not.0.in
net xstep-neg not.0.out => parport.0.pin-03-out