conv_s32_u32 problem
- rafferty
- Offline
- Premium Member
Less
More
- Posts: 83
- Thank you received: 11
21 Jun 2021 06:55 #212539
by rafferty
conv_s32_u32 problem was created by rafferty
I now have PathPilot V2.7.4 up and running - on the day they released 2.8.0!
My aim is to have a high speed spindle so I had a quick look at extracting a select bit from tormachspindle.spindle-type, an s32. Values are 0 standard spindle, 1 speeder (geared up standard spindle) and 3 high speed spindle.
The error I get is:
I can't see what the problem is, likely obvious but not to me. So would some one wit a bit more nouse than me take a look please.
Relevant bits of ini file:(line nos not in file)
PathPilot V2 is LinuxCNC 2.8.0~pre1 but because Tormach deleted unsed hal so files from rtlib I replaced the rtlib dir with one from a local build of 2.7.8 which has conv_s32_u32.so. Up till now has worked without a problem.
Ken
My aim is to have a high speed spindle so I had a quick look at extracting a select bit from tormachspindle.spindle-type, an s32. Values are 0 standard spindle, 1 speeder (geared up standard spindle) and 3 high speed spindle.
The error I get is:
HAL: ERROR: function 'conv_s32_u32' not found
sieg_sx3_mill_5i25.hal:93: addf failed
HALCMD ini file /home/operator/tmc/configs/tormach_mill/tormach_1100-3.ini load failed with config file sieg_sx3_mill_5i25.hal
I can't see what the problem is, likely obvious but not to me. So would some one wit a bit more nouse than me take a look please.
Relevant bits of ini file:
30 loadrt conv_s32_u32 count=1
31 loadrt bitslice names=spindle_select-bits personality=2
...
93 addf conv_s32_u32 servo-thread
94 addf spindle_select-bits servo-thread
...
222 # lo/!hi signal derrived from tormachspindle.spindle-type
223 # 0 for sieg spindle, 2 for high speed spindle
224 # inverted bit 1 is HI for lo speed and LO for hi speed spindle
225 setp hm2_[HOSTMOT2](BOARD).0.gpio.019.is_output 0
226 setp hm2_[HOSTMOT2](BOARD).0.gpio.019.invert_output 1
227 net spindle-type conv_s32_u32.in
227 net spindle-select_u32 conv_s32_u32.out spindle_select-bits.in
228 net spindle_selected-bit spindle_select-bits.out-01 hm2_[HOSTMOT2](BOARD).0.gpio.019.out
PathPilot V2 is LinuxCNC 2.8.0~pre1 but because Tormach deleted unsed hal so files from rtlib I replaced the rtlib dir with one from a local build of 2.7.8 which has conv_s32_u32.so. Up till now has worked without a problem.
Ken
Please Log in or Create an account to join the conversation.
- andypugh
- Offline
- Moderator
Less
More
- Posts: 23310
- Thank you received: 4858
21 Jun 2021 23:41 #212615
by andypugh
Replied by andypugh on topic conv_s32_u32 problem
I assume that they don't include halcompile?
Please Log in or Create an account to join the conversation.
- rafferty
- Offline
- Premium Member
Less
More
- Posts: 83
- Thank you received: 11
23 Jun 2021 14:09 #212745
by rafferty
Well assumed.
Plan is to install "LinuxCNC 2.8.0 Debian 10 Buster PREEMPT-RT ISO" on a spare drive and use rtlib from there and also get halcompile and whatever it needs. They did leave gcc.
One little question while you're there, in the conv_s32_u32.comp file are :
#if 0 != 0
and
#if 0 != -1
Similar things in other conv comps, can't figure them out.
They propagate to the c file, what is their purpose?
Ken.
Replied by rafferty on topic conv_s32_u32 problem
I assume that they don't include halcompile?
Well assumed.
Plan is to install "LinuxCNC 2.8.0 Debian 10 Buster PREEMPT-RT ISO" on a spare drive and use rtlib from there and also get halcompile and whatever it needs. They did leave gcc.
One little question while you're there, in the conv_s32_u32.comp file are :
#if 0 != 0
and
#if 0 != -1
Similar things in other conv comps, can't figure them out.
They propagate to the c file, what is their purpose?
Ken.
Please Log in or Create an account to join the conversation.
- andypugh
- Offline
- Moderator
Less
More
- Posts: 23310
- Thank you received: 4858
24 Jun 2021 13:55 #212823
by andypugh
Replied by andypugh on topic conv_s32_u32 problem
The files are generated by
github.com/LinuxCNC/linuxcnc/blob/master...ponents/conv.comp.in
And
github.com/LinuxCNC/linuxcnc/blob/master...ents/Submakefile#L83
ie, there are not separate .comp files for each one (to be honest I think that separate .comp files would be simpler, but this way makes it easier to expand to new data types)
So, the #if conditional compiles are used to enforce limits, where needed.
github.com/LinuxCNC/linuxcnc/blob/master...ponents/conv.comp.in
And
github.com/LinuxCNC/linuxcnc/blob/master...ents/Submakefile#L83
ie, there are not separate .comp files for each one (to be honest I think that separate .comp files would be simpler, but this way makes it easier to expand to new data types)
So, the #if conditional compiles are used to enforce limits, where needed.
Please Log in or Create an account to join the conversation.
- rafferty
- Offline
- Premium Member
Less
More
- Posts: 83
- Thank you received: 11
25 Jun 2021 09:51 #212890
by rafferty
Replied by rafferty on topic conv_s32_u32 problem
Thanks for the explanation of the #if statements.
Unfortunately still no joy with the conv_s21_u32 comp.
I built 2.8.0~pre1 and I can 'halcmd loadrt conv_s21_u32' there as expected.
(I believe PathPilot 2 uses 2.8.0~pre1)
Then copied all the 2.8.0 so files in to PathPilot's rtlib and everything works except conv_s21_u32. My three home grown comp files work too.
I tested all the 2.8.0~pre1 conv*.so files and they all fail with the same error as in 1st post.
Do the conversion comps rely on something else being loaded or available?
I'd love to sort this out but I can always do a another home grown comp to do what I want.
Ken.
Unfortunately still no joy with the conv_s21_u32 comp.
I built 2.8.0~pre1 and I can 'halcmd loadrt conv_s21_u32' there as expected.
(I believe PathPilot 2 uses 2.8.0~pre1)
Then copied all the 2.8.0 so files in to PathPilot's rtlib and everything works except conv_s21_u32. My three home grown comp files work too.
I tested all the 2.8.0~pre1 conv*.so files and they all fail with the same error as in 1st post.
Do the conversion comps rely on something else being loaded or available?
I'd love to sort this out but I can always do a another home grown comp to do what I want.
Ken.
Please Log in or Create an account to join the conversation.
- MaHa
- Offline
- Platinum Member
Less
More
- Posts: 398
- Thank you received: 160
25 Jun 2021 10:36 #212892
by MaHa
Replied by MaHa on topic conv_s32_u32 problem
For my configuration, Linuxcnc, underscores used only when
loadrt conv_s32_u32
For usage of pins, minus used.
conv-s32-u32
loadrt conv_s32_u32
For usage of pins, minus used.
conv-s32-u32
Please Log in or Create an account to join the conversation.
- rafferty
- Offline
- Premium Member
Less
More
- Posts: 83
- Thank you received: 11
26 Jun 2021 01:29 #212937
by rafferty
Replied by rafferty on topic conv_s32_u32 problem
Thanks for your reply, it made me examine the hal file and realise there were a couple of errors, it should be:
I was missing the '0' where conv_s32_u32 is referenced in the "addf" and two "net" lines.
I've also got rid of the named bitslice component with "_" and "-" in it which was just my carelessness, it's now bitslice.0
But the bad news is it still fails with the same error.
Not sure about what you say and happy to be told I'm wrong but I think you are mixing component names with signal names:
The names with '_' underscores refer to the component but conv-s32-u32-in with the "-" is a poorly chosen and confusing signal name that connects to the input pin of the component. tooth-guitar-window would be a valid signal name in its place (and still confusing).
Ken
30 loadrt conv_s32_u32 count=1
93 addf conv_s32_u32.0 servo-thread
227 net spindle-type conv_s32_u32.0.in
227 net spindle-select_u32 conv_s32_u32.0.out spindle_select-bits.in
I was missing the '0' where conv_s32_u32 is referenced in the "addf" and two "net" lines.
I've also got rid of the named bitslice component with "_" and "-" in it which was just my carelessness, it's now bitslice.0
But the bad news is it still fails with the same error.
For my configuration, Linuxcnc, underscores used only when
loadrt conv_s32_u32
For usage of pins, minus used.
conv-s32-u32
Not sure about what you say and happy to be told I'm wrong but I think you are mixing component names with signal names:
loadrt conv_s32_u32 count=1
addf conv_s32_u32.0 servo thread
net conv-s32-u32-in conv_s32_u32.0.in
The names with '_' underscores refer to the component but conv-s32-u32-in with the "-" is a poorly chosen and confusing signal name that connects to the input pin of the component. tooth-guitar-window would be a valid signal name in its place (and still confusing).
Ken
Please Log in or Create an account to join the conversation.
- phillc54
- Away
- Platinum Member
Less
More
- Posts: 5698
- Thank you received: 2082
26 Jun 2021 02:23 - 26 Jun 2021 02:31 #212940
by phillc54
Replied by phillc54 on topic conv_s32_u32 problem
I think MaHa is on the right track, this is from a halrun session:
It does show the correct format in the docs:
linuxcnc.org/docs/html/man/man9/conv_s32_u32.9.html
mx-py2:~ $ halrun
halcmd: loadrt threads
Note: Using POSIX realtime
halcmd: loadrt conv_s32_u32
halcmd: addf conv_s32_u32.0 thread1
HAL: ERROR: function 'conv_s32_u32.0' not found
<stdin>:5: addf failed
halcmd: addf conv-s32-u32.0 thread1
halcmd: show pin
Component Pins:
Owner Type Dir Value Name
10 s32 IN 0 conv-s32-u32.0.in
10 u32 OUT 0x00000000 conv-s32-u32.0.out
10 bit OUT FALSE conv-s32-u32.0.out-of-range
10 s32 OUT 0 conv-s32-u32.0.time
5 s32 OUT 0 thread1.time
halcmd: Note: Using POSIX realtime
mx-py2:~ $
It does show the correct format in the docs:
linuxcnc.org/docs/html/man/man9/conv_s32_u32.9.html
Last edit: 26 Jun 2021 02:31 by phillc54.
Please Log in or Create an account to join the conversation.
- rafferty
- Offline
- Premium Member
Less
More
- Posts: 83
- Thank you received: 11
26 Jun 2021 04:52 #212946
by rafferty
Replied by rafferty on topic conv_s32_u32 problem
OK, I got it wrong.
Apologies of the first order to MaHa, and thanks to philc54 for backing him.
This is a bit of a shock, I thought I was getting some understanding but it seems not.
What's happened is that I've been naming components like:
loadrt flipflop names=last-spindle-direction-latch
loadrt range names=tach-range
So the pin names have the '-' and I've got away with it
A a bit surprised that it's taken about two years of on and off moding hal files for it to bite me.
Thankyou both for putting me straight.
Ken.
Apologies of the first order to MaHa, and thanks to philc54 for backing him.
This is a bit of a shock, I thought I was getting some understanding but it seems not.
What's happened is that I've been naming components like:
loadrt flipflop names=last-spindle-direction-latch
loadrt range names=tach-range
So the pin names have the '-' and I've got away with it
A a bit surprised that it's taken about two years of on and off moding hal files for it to bite me.
Thankyou both for putting me straight.
Ken.
Please Log in or Create an account to join the conversation.
- phillc54
- Away
- Platinum Member
Less
More
- Posts: 5698
- Thank you received: 2082
26 Jun 2021 05:51 #212947
by phillc54
Replied by phillc54 on topic conv_s32_u32 problem
If you had done the same with conv_s32_u32 then you probably would not have noticed:
mx-py2:~ $ halrun
halcmd: loadrt threads
Note: Using POSIX realtime
halcmd: loadrt conv_s32_u32 names=my-converter
halcmd: addf my-converter thread1
halcmd: show pin
Component Pins:
Owner Type Dir Value Name
8 s32 IN 0 my-converter.in
8 u32 OUT 0x00000000 my-converter.out
8 bit OUT FALSE my-converter.out-of-range
8 s32 OUT 0 my-converter.time
5 s32 OUT 0 thread1.time
halcmd: Note: Using POSIX realtime
mx-py2:~ $
Please Log in or Create an account to join the conversation.
Time to create page: 0.078 seconds