Advanced Search

Yes, I get that, but it seems you're using a different version of CIA402_home_comp than the one i posted there. Which one is it? I have everything working in the ethercat setup but the homing was the regular one.

I suspect its a hardware fault. Its a long time since I've used 2.9 on a live machine but it never happened to me.
Can you swap out the keyboard for another one? Some compressed air to blow out the keys perhaps?

Hold on—you need to make a distinction.
There are two fundamental homing methods:
1. LinuxCNC Homing
2. CiA-402 Homing using the CIA402_home_comp.
Your machine should first be running entirely under EtherCAT. The internal servo homing using CIA402_home_comp.comp should function without any issues.
Only then can you proceed to implement the topic discussed here.

I think the N100's will be OK but never tried them
If you want cheap, look for a surplus DELL or HP corporate desktop with an i5, 8 gb RAM, Intel NIC
I nearly bought a DELL the other day for AUD $80 (< USD $60)
I'd also look for 1080p video. I have had one here for ages and found out today it had a Displayport monitor output and I had even bought a VGA to HDMI adapter to use it! (that went in the bin)

What are PC specs. cpu, number of cores,  RAM. 

There is no magic as far as I know....
Is this not something you can deal with in the post-processor?
Like Ssetting a global before the M6, e.g. #<_restore_xy> = 0, and have your M6 read that flag to decide whether to restore?

Linuxcnc architecture will fight you hard on this, no real way to know the future move type after an M6, preview does it, but is fragile, it would be a waste of time implementing something like that IMO

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.