HAL logic overhead?
16 Sep 2018 02:20 #117589
by blazini36
HAL logic overhead? was created by blazini36
I have a program/machine that require using an external "index" sensor to reset an encoder and then use the encoder to trigger an output on a variable number of counts. The trick is that the sensor must count the pulses before it resets the encoder because it must skip a set number. This actually requires quite a bit of logic.
Early on a programmer wrote a component for me to handle this. It seemed to work fine at the time, but as the program was expanded and things were added I realized there were logic issues with this component for my use. I cannot write in standard programming languages, but I've gotten pretty familiar with HAL. I wrote a custom HAL file that contains 2 comparators, an updown, an and and 2 oneshots. I also have to convert signed integers to and from floats on 2 occasions in this file. I basically use this HAL file as if it were a component where I carry signals in and out of it to the main HAL file and postgui hal file. I've gotten into the habit of using kicad to make electrical drawings of hal logic to try to keep track of what's going on,
So far this works perfectly fine other than a minor logic issue I think I've sorted out. The only thing I'm wondering is since hal components are basically small compiled C programs if this is incurring much if any overhead over having a single component that handles this.
Early on a programmer wrote a component for me to handle this. It seemed to work fine at the time, but as the program was expanded and things were added I realized there were logic issues with this component for my use. I cannot write in standard programming languages, but I've gotten pretty familiar with HAL. I wrote a custom HAL file that contains 2 comparators, an updown, an and and 2 oneshots. I also have to convert signed integers to and from floats on 2 occasions in this file. I basically use this HAL file as if it were a component where I carry signals in and out of it to the main HAL file and postgui hal file. I've gotten into the habit of using kicad to make electrical drawings of hal logic to try to keep track of what's going on,
So far this works perfectly fine other than a minor logic issue I think I've sorted out. The only thing I'm wondering is since hal components are basically small compiled C programs if this is incurring much if any overhead over having a single component that handles this.
Please Log in or Create an account to join the conversation.
16 Sep 2018 03:01 #117592
by dgarrett
Replied by dgarrett on topic HAL logic overhead?
You can monitor any component's execution time (in cpu clocks
not seconds) using supplied commands like halmeter, halshow, or halscope.
The '.time' pins available for any loaded component can be shown
(while LinuxCNC is running) with:
Example (using a common sim like: configs/sim/axis/axis.ini):
For more statistical details, you can use the supplied program
named hal-histogram for any hal pin. Docs:
linuxcnc.org/docs/2.7/html/hal/tools.html#_hal_histogram
Example (for a running axis.ini sim):
Adjust the minval,bsize,nbins as required.
A demo sim config is provided as:
configs/sim/axis/histogram_demo.ini
not seconds) using supplied commands like halmeter, halshow, or halscope.
The '.time' pins available for any loaded component can be shown
(while LinuxCNC is running) with:
$ halcmd show pin \*.timeExample (using a common sim like: configs/sim/axis/axis.ini):
$ halcmd show pin vel\*.time
Component Pins:
Owner Type Dir Value Name
28 s32 OUT 311 vel_xy.time
28 s32 OUT 112 vel_xyz.timeFor more statistical details, you can use the supplied program
named hal-histogram for any hal pin. Docs:
linuxcnc.org/docs/2.7/html/hal/tools.html#_hal_histogram
Example (for a running axis.ini sim):
$ hal-histogram vel_xy.time&Adjust the minval,bsize,nbins as required.
A demo sim config is provided as:
configs/sim/axis/histogram_demo.ini
The following user(s) said Thank You: jtc
Please Log in or Create an account to join the conversation.
Time to create page: 0.058 seconds