Advanced Search

That might be a question for Sorotec. They also offer grease guns and lubrication products, and should be able to make a recommendation:

www.sorotec.de/shop/Tools-and-utilities/...roducts/Lubrication/

HGH20CA is a Hiwin part number, although I suspect that Sorotec is selling generic clones. Hiwin has an extensive linear guide and ballscrew lubrication guide at the following link (737KB PDF). They recommend viscosity grade NGLI 2, and list specific greases (see attached table).

www.hiwin.com/wp-content/uploads/lubricating_instructions.pdf
 

Subject: Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Hi all,

I’d like to open a technical discussion about a project I’ve been working on, io_decoder, focusing on the software solution I've implemented to handle USB communication within LinuxCNC.

I am well aware that in the official LinuxCNC documentation and Wiki, USB is often described as 'the evil' (or, more formally, as 'not suitable for real-time control'). However, if one looks closely at the context of those warnings, they are strictly related to step generation and primary motion control, where microsecond-level jitter is fatal.

For HMI panels, MPGs, and secondary I/O, I believe this 'dogma' can be challenged if the HAL component is designed to manage the USB stack correctly. My goal is to allow users with complex retrofits (like those using Mesa 7i80/7i92) to offload all non-critical I/O to a single USB bus, freeing up high-speed pins and reducing the 'wiring nightmare' and EMI risks.

To test the limits of my custom HAL component, I’ve pushed it to handle real-time axis tracking via an encoder (not just simple buttons).

You can see the fluid response in this playlist: 
www.youtube.com/playlist?list=PL9D_TSVxg...tA9_k6njBeVTL0IYY7Ct

In other communities, the mere mention of 'USB' triggers an immediate rejection. I’m posting here because I’d like a more nuanced, engineering-focused feedback:

1. Given that a human operator has a reaction time of ~200ms, is a stable 20ms update cycle (50Hz) really a bottleneck for MPG tracking or HMI interaction, considering it's handled by a dedicated non-blocking HAL component?

2. How can I further improve the HAL component to make the communication even more robust against bus jitter?

The project is Open Source and I'm looking for peers to discuss the driver implementation rather than the hardware itself. What do you think about the responsiveness shown in the videos?

Documentation & Wiring: 
bobwolfrst.github.io/io_decoder-linuxCNC/

Best regards,
Roberto

So to use a custom panel you have made in Qt designer.
Say the panel name will be 'test.ui'
save the panel in your configuration folder in qtvcp/panels/test/ as test.ui

then in the ini under [DISPLAY]

EMBED_TAB_NAME=demo
EMBED_TAB_COMMAND=qtvcp test
EMBED_TAB_LOCATION=DIALOG

please give feedback on any problems or needs.

Chris

Ok it doesn't matter, this works in master or 2.9

Add the file to qtvcp/screens/qtdragon/ it will be in your configuration folder.
name the file qtdragon_handler.py

Then in your ini add this under the [DISPLAY] heading (this is an example):

# optional tab showing an external qtvcp panel
EMBED_TAB_NAME=Vismach demo
EMBED_TAB_COMMAND=qtvcp vismach_mill_xyz
EMBED_TAB_LOCATION=DIALOG

The key thing is the location: DIALOG will make the panel be a popup dialog.
You will see an arrow button show on the top right of qtdragon.
pushing it will toggle the dialog. There is also a HAL pin you could use to do the same.



 

I need a little guide on how to set up a tool changer. This is a new to me Okuma MC30-VA. I already have two machines running linuxcnc but both of them don't have tool changers. I'm aware of the carousel component but the way this is setup is kind of baffling.

 


1st issue is that the tool magazine doesn't have any sort of position sensors. No proximity switches. It's driven by an absolute servo and I think the tool pot position is stored as a rotary axis. so I need to put an absolute servo for that.

2nd one is the tool changer arm has an induction motor with a built in brake. it's kind of sticky and I think the brake is on it's way out. so I would like to put a servo for that too. Tool changer arm has 4 proximity switches (probably gray code)

I'm planning to use ethercat for this one and I think we can use 3 axis + 2 tool changer axis for this.
So how do I command these extra 2 axis with the ethercat. My initial thought is using them as two rotary axis with absolute encoders. But don't need them to be in the GUI. Can anyone offer some help?  

 

I forgot to ask if you are using 2.9 or master version? I have this working in principal in master branch.

Thank you for your suggestion automata, we are aware and taking into consideration all known approaches, bi-arc, spline, clothoids, quintic etc...
These are substantial changes which may need a separate branch, or a different planner again planner_type 2 or more.
As of now we are concentrating efforts on fixing the spikes that have been reported, and I've had some success, not ready to share the code yet, probably next week, but I will share a picture of my current results, I've used mainly Rüdiger's code for testing, but also Endian's and Peter's PCW. A special thank you goes to ruediger123 for making the simple rhombus code. I love it because it's very quick to test and shows the blending issues very well. This was the original code what is now in master linuxcnc running the rhombus with G64 p0.25 to accentuate the issue


And this is same code after some blending and cubic improvements, note that YangYang's code sp_scurve itself has not changes a single dot.
 
As I mentioned before the main issues were not in the scurve code itself but in the architecture around it that needed to be tweaked, or possibly be rebuilt ground up, but that's for another time.

As of  now the three big improvements/tweaks are:
1- making a bigger blending arc (still within G64 Pxx tolerance)
2- reduce velocity when blending (inevitable to avoid spikes)
3- limiting how much the cubic interpolation coefficient 'a' can change between segments - the cubic interpolation done after the kinematics was screwing up YangYang's smooth curves

Anyhow next week we are planning on refining and cleaning up the code, YangYang will work on tpOptimizePlannerMotions, I will do testing or real hardware not just scope reads, test latency as well. We may have a PR ready end of next week, but no promises.

I was also suspecting SPI is the issue, since as soon as I use SPI for tmc5160, The blinking LED which I configured to know if firmware is working, glows continuously insteed of blinking.
There is somthing different in ben-jecobson F4 port, since console output on uart gives garbage, no readable output.

As per your suggestion, I comapred both repos, for TMCsteppers both are same, no changes. And both F4 and H7 uses software SPI for tmc communication.

Hi Mario,

The first step would be to share your HAL and INI files, as the configuration of your machine will be done in there. I don't know how deep you already went with the Linuxcnc documentation, but to keep it simple the INI file will describe your machine (axis number, axis travel and speed limits, type of GUI and many other) and your HAL file will describe the modules running in your threads (typically base and servo) and the connection between them.

Cheers, Luca

Usually no, but i had new cables not work properly, occasionally.

Thank you very much. It really cleared things up. I'll dig around a bit more and get back.

mods should also remove the old name from this thread too.

done

Good news.  Having some success.  I have xyz moving and i have spindle brake and mist toggling on and off in halshow(which i have learned to use); I even got my mist working but grok says i have it backwards and i hope i have not damaged the board because wired 24 v + to solenoid    and solenoid - to output +    and out - to   ground.  It did not work when i wired it solenoid - to out - 

I have a huanyang gt 7.5 kw vfd  it is different from the non gt and its pins i had been using with uccnc are
s1    s2   grnd(may have been +10 the wire pulled off as I was looking at it)  Ai1 and comm     I am going to the shop soon and will post my files I will see if i get any led light on the board when I m3 if there are any.  Is there someone else who has wired a gt vfd that could tell me what worked for them.  Also ready to do encoder wiring. what pins would those be? Thanks in advance and i will be posting soon.   In uccnc  I had a custom button to put the spindle brake on when changing tool because i have a quick change nut on my Bridgeport series 2.

mods should also remove the old name from this thread too.

harindugamlath wrote:

Do you know how the ethercat control loop actually works?

Here is a slide deck from a presentation on Erhercat by Martin Rostan, the ETG president in Germany I went to when he was in Australia
vmnet.com.au:10003/d/s/13FfcZqiooYngfrLX...XlFwmcTS-l7mgkSOi5gw

Roughly, In the drive a target position and target velocity is updated by linuxcnc.  The ethercat bus uses synchronized clocks to keep the slaves in sync and that Is synced to the Linuxcnc servo thread. Our linuxcnc driver (lcec) reads the bus at the beginning of the servo thread and written out at the end of the servo thread (the position of addfs in your hal file are important to achieve this lcec.read-all and lcec.write-all).
example hal: github.com/rodw-au/linuxcnc-cia402/blob/main/cia402.hal
So Linuxcnc gets a chance to update slave parameters every servo thread cycle

The best analogy in the presentation is the high speed train and the slaves are a station. Packets can get on and off the train as the packet passes through the station without the train stopping which is what our driver does in a single sevo thread loop via the order of the addfs.

Note that CNC is a small subset of Ethercat use as the majority of devices are deployed in factory automation. There are other field bus technologies mentioned in the PDF (and perhaps Mesa's hm2_eth driver) that compete but they are based on standard TCP/IP packets and while Ethercat also uses TCP/IP (perhaps TCP/IP are the wheels on the train). But Ethercat is much more efficient (lean) protocol so it performs better.

Interesting that competitors Profinet et al are sponsors of TSN (Time sensitive Networking) which is in a set of standard for Real time networking. They need it. Ethercat also supports it, but does not really need to due to is better efficiency. I'm not sure if the iGh Ethercat master we use supports TSN but it also requires TSN support on the NIC's on the slaves. That is another emerging story.

Hope I have not told too many lies here.