Advanced Search

The issue with the original code was it was developed with a machine that homes to index so it does not work cleanly with home to sensor. The real problem  is that during device homing, Linuxcnc throws following errors because it has not commanded movement. What generally needs to happen is the position feedback is synced with commanded position so Linuxcnc is happy. This is why most working solutions also provide their own cia402.comp

Yes, I think homing can be standardized for cia402 devices and the new home comp is there now to support that. So much of homing.c becomes irrelavent with device homing so the homecomp allows control of what is needed. I've had a couple of goes at it. The first was obsoleted by a rewrite of the homecomp paradigm.

The cia402 state machine is actually very simple. very linear with the exception of error and safety steps to prior states. The flowchart here is a good resource
www.kebamerica.com/blog/comprehensive-gu...a-402-drive-profile/

Anyway, back on task. It occurred to me that I had included some standard PDO's that are not reported by Ethercat pdos. I will revisit that. 

 

Thanks for your reply @andypugh

I copied and pasted your suggestion into my HAL file, replacing the original erroneous text.

Unfortunately when launching Linuxcnc, an error is shown up as attached in the .png file.

Revised HAL file also attached.

Regards

Phil

I mostly run G64 P0.05 in metric, G64 P0.002 in inches, G61 is afterthought for us, but will be tested...

the on screen button and physical button cannot remain synchronized as the screen cannot physically change the mushroom buttons state. so you will need to add in some hal NOT allowing the UI estop button in probe basic to be in a state different from the physical mushroom button.

github.com/LinuxCNC/linuxcnc/issues/3717

(No solution yet)

You could quickly check if those have the desired affect by opening halshow, opening the "watch" tab and picking those pins from the tree. Then you can set values directly.

If that works then link them up in HAL.

One advantage of the Pi is that it is perfectly reasonable to have an identical spare to swap in in case of trouble.

This feels like possibly a race condition, I wonder what happens if the queue-empty check is just disabled?
(ie, I wonder if it indicates a real problem?)

I use gmoccapy.

So far, I have found that these two signals control the feed rate:
gmocacapy.spc-feed.value
gmocacapy.spc-speed.value

Which GUI are you using?

If this is your whole HAL file then the problem is that you have connected the HAL "net" to the VFD but not to the motion contoller.

This creates "nets" with names like "spindle" enable but there is nothing at the other "end"

Try:

The => are optional and ignored by the computer.

linuxcnc.org/docs/stable/html/man/man9/m....html#SPINDLE%20PINS

Sorry, I must have got distracted when changing the variable name and didn't finish changing every occurrence. The bug has been squashed.

JT

I have sent a query about how it interfaces. If it is USB HID then it will probably work fine with hal_input. Otherwise it might need a specific driver.

Hi,

dein Fehler könnte möglicherweise noch eine weitere Ursache haben.
Da dies beim abbremsen und hohen Geschwindigkeiten passiert, kann es sein, dass dein Servotreiber die überschüssige Generatorenergie 
vom Servomotor nicht wegbekommt und sich dabei der Zwischenkreis entläd.
Hast du Bremswiederstände installiert?

Hi,
I have a question about the configuration of the XHC WHB04B-06.
I already asked this question in the German forum but unfortunately did not receive an answer.
First of all, the handwheel works perfectly except for the rotary knob button.
Here I can only set the increments. But I also want to control the feed rates.

I think the settings need to be adjusted here:

# GUI feed rate related signals can be used when program is running moving GUI slider
net pdnt.feed-override.scale whb.halui.feed-override.scale halui.feed-override.scale # needed for both FeedOverride+/- and rotary knob button
net pdnt.max-velocity.value whb.halui.max-velocity.value halui.max-velocity.value # needed for Mpg mode : button feed position% * max-velocity = Mpg feedrate

# take feed override min/max values from/to the GUI
net pdnt.feed-override.value halui.feed-override.value whb.halui.feed-override.value # GUI feed rate related signals
net pdnt.feed-override.increase whb.halui.feed-override.increase halui.feed-override.increase
net pdnt.feed-override.decrease whb.halui.feed-override.decrease halui.feed-override.decrease


I just don't know which ones?