Advanced Search

Considering the Atom N450 is a single core CPU I'm unsure how isolating a core that doesn't exist would work.
You may get better latency if you disable Hyperthreading.
I'm assuming you are going to use the parallel port.

Thanking you kindly sir.

unknown wrote:

Does this mean I should remove the link to the RPi5/4 images I've been working on. Which I have no issue with if this is the way it should be.

Cheers
Rob

If you mean the GitHub link, no, you don’t need to remove it. It’s not a mirror. It’s your own work and it’s been communicated as such.

That is not the image I'm referring to. That image has been uploaded via one of the mods.
I don't not have access to any of the Linuxcnc resources. Even if I did I would ensure that the image was vetted and approved by others.

tommylight wrote:

Not near a machine so i can not confirm this, but IIRC:
Yes it does Disable the machine.
No, it does not trigger e-stop.

Near as I can tell, this is correct. It disables the the machine, requiring it to be re-enabled, but it does not turn the machine state to "OFF". This is why you see the GUI turn "OFF", and halui.machine.is-on turns False. But that's not the same as toggling halui.machine.off. I don't think this is a bug, I think this is a misunderstanding of what happens when a amp-fault is triggered. If you want this to work, I think the best course of action would be to connect the pin to machine.off as suggested previously.

github.com/LinuxCNC/linuxcnc/blob/69d26e...otion/control.c#L838

Does this mean I should remove the link to the RPi5/4 images I've been working on. Which I have no issue with if this is the way it should be.

Cheers
Rob

Posts with links to non-sanctioned mirrors of forum content, ISO downloads, and/or other LinuxCNC content are not permitted and will be removed.

Posting such links may result in moderator action which includes being banned from the forum.

Thank you for your cooperation.

7C81 configuration for 7I78 on P1, INM on first 12 P2 pins

The inm module supports up to 4 MPG encoders,
it also has built in input filtering/debouncing.

The last 5 P2 pins are left as GPIO so can be inputs/outputs
as needed


 

 

What exactly do you mean by: Adding second spindle control to pyvcp?

It seems very strange to me because it works perfectly fine for me on several machines where I've installed potentiometers to control those two speeds. I honestly don't know the resolution of the ADCs on the card you're using. In my case, the control is very linear between 0%, 100%, and 200%, which is the range in which I have those two overrider speeds programmed. Could you please repost your configuration so I can try to help you?

I've put together that userspace component to get the temperatures, and it works just fine.

andrax wrote:

As I see it, and hopefully I have understood correctly, the drives are put into homing mode (0x6060 = 6).
The servos perform the homing independently. 
The homing status can be read via 0x6041 bit 15.
The evaluation is performed by cia402homecomp.comp and reports Linuxcnc homing completed.
Is that correct?

 

That sounds correct.

I just put together a robot that homes using the drives. I didn't want a separate home switch, so I home each axis using the negative overtravel switch, and method 1 (Feed negative until negative overtravel goes logic high, then feed positive to the next index pulse).

All you must do is connect your negative overtravel switch to DI2. Home switch signals don't go through HAL in this application.

You might try the cia402 component from github.com/dbraun1981/hal-cia402. It has homing built in, and you don't need to touch the controlword register yourself.

It's the same for all EoE-enabled slaves, not just this one.

Ethercat master creates a handler, documentation page 104 docs.etherlab.org/ethercat/1.6/pdf/ethercat_doc.pdf

Creation of EoE Handlers
During bus scanning (see section 5.4), the master deter-
mines the supported mailbox protocols for each slave. This is done by examining the
“Supported Mailbox Protocols” mask field at word address 0x001C of the SII. If bit
1 is set, the slave supports the EoE protocol. In this case, an EoE handler is created
for that slave.

The queue in the EoE handler needs to be processed by the EoE state machine. And that is what doesn't happen.
The queue gets filled up and everything stops. Lcec should process the queue regularly when
in cyclous mode, to get packets in and out. That's the code that need to be in place and I think
that is what grok and Chatgpt both are proposing. And also kworm identified that.
Three out of three, majority win right?, so I think that's what's needs to be done.

There is no disabling of EoE support in the Ethercat master code. As in the quote above, if byte 0x38 (word 0x1c) is "1"
in the right place, EoE handlers are created, queue gets built up and everything stops.

What people do are 
1. Read out the eeprom and change that "1" in byte 0x38 to "0" and write back the new eeprom contents to the drive.
Ethercat master will then identify no support for EoE and go on with that track.
2. Disable EoE altogether in the Ethercat master with ./configure --disable-eoe during build.
The outcome is the same as above. No EoE processing, no queues that build up.

So what is broken and what isn't? Don't fix what isn't broken. It looks like the Ethercat master is broken, but that is not the case.
It is doing its part. Lcec on the other hand doesn't do what it should do to make EoE work. Lcec should regularly
process the EoE queue that are being built up. That's what needs to be added.

I have looked at what I have and I don't have any equipment with EoE to practice on. 
I can always buy one, it's an interesting enough task, but EoE servo drives seems to cost multum.
And I haven't really found one. Looks like I'll be standing on the sidelines cheering.


 

By "shutdown" I mean what the clearpath's enable signal does - the power supply is still running but the drive does not try to hold position any more, so the axis is able to move freely. Shutting down servo drives on following error allows humans to manually move the machine, potentially a life-saving ability, but at least it takes pressure off whatever it hit.

All my power supplies themselves are hooked into the estop chain, but that's for a different type of emergency

My point with modern step-servos is that, WHEN you shut it down / disable it, you no longer know what the machine's position is, because there's no position feedback to linuxcnc. The machine can move without linuxcnc knowing, hence the VOLATILE_HOME.

With "old style" servo configurations, linuxcnc had direct access to the encoders, so could track non-powered motion too.

Normally it will only need to switch once when he selects a different speed. Google: "cvt mill belt drive"