Advanced Search

unknown wrote:

rodw wrote:

. I'd get confirmation that the commit for 6.11 will work for 6.12.

It seems to be confirmed because the notes say it fixes issue #160 which is the issue I raised. 
gitlab.com/etherlab.org/ethercat/-/merge_requests/151

in probe basic the user parameters you enter for things like probing and tool setting etc are stored in the var file and then can be called upon in subroutines/macros. in this regard probe basic will have a user setup page where you can enter in parameters that would determine rack location (along X axis or along Y axis), axis row centerline position, pocket spacing, number of pockets, pickup height, clearance height, special considerations such as air blast activation, dust boot clearance motion activation, tool touch off options etc.

I spent some time last night and will spend some more time this morning working on adding multiple atc options in the ini to load either not atc tab, carousel atc tab or rack atc tab. i got most of that sorted last night but want to refine it a bit and then i will start work on the actual rack graphics and setup page and subroutines.

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?