Advanced Search

Good job my friend!
Can you provide any paper or info of the math background you used for it?

I bought a similar grease gun. You can get cheaper ones off ebay if you search for Jiabara threaded style for 70-80 gram tubes. 
The tubes are a clever accordion that screws onto the grease gun.
I did not like the nozzle/rigid stem. It locks on really tight. So maybe the real deal works better.
If you have old LM blocks with brittle plastic, you risk the chance of pulling the grease fitting out of the plastic threads. 
Be aware that some manufacturers use grease fittings with an odd pitch of M6x0.75! In case you need to modify something.

I have a machine that recommends 2 different greases. NSK Grs AS2 for the LM blocks and LR3 for the ball screws. AS2 is probably fine for both. 

I'm thinking of adding a centralized lubrication system to my current project instead of trying to access each block under the way covers. 
I have used Bijur pump and metering units adapted to ball screws and LM guides in the past using vactra no2.
I'm interested in finding out what others are doing that is more of a modern system. 
I know Haas went through a couple of redesigns with their remote lube/grease systems.
 

Did you try lowering the acceleration?
The default of 750mm/s/s is to much for some machines.

github.com/grandixximo/linuxcnc/tree/9d

This is phase 0 completed, according to my plan, this is extremely experimental work in progress, there are known issues at the moment, no arcs no blends, no scurve, as illustrated by the plan you can find at this post, which I got not much feedback..

forum.linuxcnc.org/38-general-linuxcnc-q...ons?start=640#341856

Next phase it is IMO too hard to be vibe coded, but I will try in my spare time.

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