Advanced Search

Dear community,

I have the following setup

Computer                Debian RT                                    XYZ closed
Vision <==(ethernet)==> Linux CNC <=========> Mesa 7i96 <=========> loop rotating
PC                        PC with dual                                platform
(CVPC)                  ethernet (CNCPC)                            (no encoders)

CVPC independently processes visual information in realtime (15-20FPS or 50-65ms) and computes the target position for the rotating platform.
This information is communicated via ethernet to CNCPC using low-latency messaging library (e.g. ZeroMQ) that has support in both python and C++.
Based on the target position information the rotating platfrom can:
a) Start movement to the given position
b) Abandon the last target position (even if the move hasn't finished yet) and update it with the newly available data. Start rapid movement to the target position.

My questions are mostly:
1. Should my component be realtime or non-realtime. Even though 15-20FPS is guaranteed, the exact timings when new position measurements arrive are not strictly defined. Communication in ZeroMQ can be blocking, i.e. wait on the function call and return if a message has arrived or non-blocking, i.e. check for new messages in a loop. So, the arrival of new data is not realtime, but target position update should be performed asap.
2. How can I update the target position in HAL (e.g. with axis or motion) such that velocity and acceleration are updated properly? As mentioned above the last movement might be still ongoing, so it has to be interrupted and the new move started.

I did my best and went through the documentation and the following forum topics:
forum.linuxcnc.org/24-hal-components/409...position-in-realtime
forum.linuxcnc.org/38-general-linuxcnc-q...ontrol-with-linuxcnc
forum.linuxcnc.org/38-general-linuxcnc-q...r-cnc-control-in-c-c
forum.linuxcnc.org/24-hal-components/528...bot-arm-in-real-time
forum.linuxcnc.org/38-general-linuxcnc-q...391-realtime-control

Unfortunately, I haven't found the recipe suitable for me. Also, there is a chance I might have overlooked the right solution cause I am still quite new to the LinuxCNC ecosystem. Any help is appreciated. Thank you!
 

rodw wrote:

There is a commit pending with etherlab or the 6.11 kernel and up which also should let ethercat on 6.12 work for us.
Bjarne at etherlab is chasing it up for us internally. He has been so helpful for us along the way.
 

I had a look at the ethercat DKMS package (extracted the package in a temporary directory, no need to do an install), and what I saw is that the source of the modules have ending with 5.14 & 6.1 before the .c .h extension (I'm guessing these are the supported kernels). I'd get confirmation that the commit for 6.11 will work for 6.12.

jairobbo wrote:

Hello everyone,

I started to work with linuxcnc only a few weeks ago, when I decided to upgrade my 3d printer with A and B axis.
Because my pi4 was starting to jitter I acquired a pi5. As one does..

I etched the image 2.94 for pi5 to an SD card. Running this image, GPIO is not working.

halcmd loadrt hal_gpio help
Note: Using POSIX realtime
Invalid parameter `help'
<commandline>:0: waitpid failed /usr/bin/rtapi_app hal_gpio
<commandline>:0: /usr/bin/rtapi_app exited without becoming ready
<commandline>:0: insmod for hal_gpio failed, returned -1
cnc@raspberrypi:~$

I dont have the knowledge to troubleshoot this. Unfortunately. Maybe somebody here know how to solve this.

kind regards,
JAiro
 

halcmd loadrt hal_gpio help
Invalid parameter `help' <<<<< this is the error from the above, Linux is pretty verbose in telling you what is wrong.

But you really need to read the man page
linuxcnc.org/docs/devel/html/drivers/hal_gpio.html

 

Thanks PCW.

Yes, I had the Ohmic sensing into the B encoder input on TB2.

Once this was unpluged, Encoder velocity stayed at 0. or flucuated to -3750.

Grounded everything i could and moved plasma source 30cm further away.

And hey presto.





 

From memory, GEANY can convert WORPAD, MS-DOS text to text format, and has a function for this in the program.

HMMM. Let's see, how much I.O. do I need? Might just try that in the future.

There is a commit pending with etherlab or the 6.11 kernel and up which also should let ethercat on 6.12 work for us.
Bjarne at etherlab is chasing it up for us internally. He has been so helpful for us along the way.

Can you share the files? Using Gcode how LCNC know where are the XYZ coordinates of a tool?

hal_gpio uses a newer method that is meant to support other ARM hardware, not just the PI. Code changes at the kernel never stops!

yes exactly, a sequence of gcode linked to the buttons on the gui
with cycle stop and error message in case something goes wrong

Hello All,

New 7i97T last year and only just got time to work in it.  I'm new to linuxcnc and mesa boards and would appreciate advice on this setup.
CR7 and CR8 switch off so FPGA initialisation is fine
Ping 192.168.1.121 works fine and green user LEDs count ethernet packets correctly
Response of Mesaflash version 3.4.9
mesaflash --device 7I97T --addr 192.168.1.121 --readhm
=  'No 7i97t board found'
 
Response of MesaCT version 2.1.7
= 'Device found at 192.168.1.121 is not a Mesa Board'

I am thinking the board should be more revealing than this and wanted to check before proceeding with linuxcnc setup.
Thanks tom

 

The images provided are not generic Debian images, as generic Debian didn't support overlays.
The images we build are custom images based on Debian repo but with kernel sources from the RPi-Linux github.

The output I gave was showing that the hal_gpio driver does indeed work, the first line is loading the driver with the GPIO config as per the man page for the driver. Yes it was the current image, with the 6.12 series kernel & Linuxcnc 2.9.4.

By macro you mean it's just a gcode sequence?

Pardon me for not posting the errormessage encountered.
I was using hal_pi_gpio since I was under the impression from the forum that it is recommended for new projects.
Under "known bugs" on the man page it says:
*
At the moment (2023-07-16) this driver only seems to work on Raspbian as the generic Debian image does not set up the correct interfaces in /dev/gpiomem and restricts access to the /sys/mem interface.
*
The error message I got was related to access to /sys/mem. Since it was a known bug I did not save and post the error-message but instead tried going the Raspbian route.


I'm not sure what to make of your output from halrun but do you mean that you are successfully using GPIOs on a Rpi5 with hal_gpio and the downloaded "standard" img?
I'm not sure where I picked up that hal_pi_gpio was the way to go but if it works with hal_gpio I suppose that is the way to go. Thoughts?

Shamelessly ripped from wiki

US inch was 25.4000508
UK inch was 25.399977

In 1930, the British Standards Institution adopted an inch of exactly 25.4 mm. The American Standards Association followed suit in 1933. By 1935, industry in 16 countries had adopted the "industrial inch" as it came to be known,[35][36] effectively endorsing Johansson's pragmatic choice of conversion ratio.[32]

In 1946, the Commonwealth Science Congress recommended a yard of exactly 0.9144 metres for adoption throughout the British Commonwealth. This was adopted by Canada in 1951;[37][38] the United States on 1 July 1959;[39][40][41] Australia in 1961,[42] effective 1 January 1964;[43] and the United Kingdom in 1963,[44] effective on 1 January 1964.[45] The new standards gave an inch of exactly 25.4 mm, 1.7 millionths of an inch longer than the old imperial inch and 2 millionths of an inch shorter than the old US inch.[46][47]

US survey inches

The United States retained the ⁠1/39.37⁠-metre definition for surveying, producing a 2 millionth part difference between standard and US survey inches.[47] This is approximately ⁠1/8⁠ inch per mile; 12.7 kilometres is exactly 500,000 standard inches and exactly 499,999 survey inches. This difference is substantial when doing calculations in State Plane Coordinate Systems with coordinate values in the hundreds of thousands or millions of feet.

In 2020, the National Institute of Standards and Technology announced that the U.S. survey foot would "be phased out" on 1 January 2023 and be superseded by the international foot (also known as the foot) equal to 0.3048 metres exactly, for all further applications.[48] This implies that the survey inch was replaced by the international inch.

What a mess.
Then the Scots & French (anything but the English way) had different ideas.