LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
20 Feb 2021 10:54 #199512
by chris@cnc
Replied by chris@cnc on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
Just an idea ...
Are all your pyvcp components in custom_gvcp.hal? That's why I had very confusing reports.
Are all your pyvcp components in custom_gvcp.hal? That's why I had very confusing reports.
Please Log in or Create an account to join the conversation.
20 Feb 2021 11:45 #199516
by andypugh
Replied by andypugh on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
Is your 2.8.1 configuration running on the same OS and machine as the 2.7.15 configuration?
It is possible that the HAL pins take up more space on a 64-bit OS than on a 32-bit OS.
There is certainly no reason to expect any difference in behaviour here between 2.7.15 and 2.8.1 caused by LinuxCNC changes alone.
It is possible that the HAL pins take up more space on a 64-bit OS than on a 32-bit OS.
There is certainly no reason to expect any difference in behaviour here between 2.7.15 and 2.8.1 caused by LinuxCNC changes alone.
Please Log in or Create an account to join the conversation.
20 Feb 2021 11:56 #199517
by gaston48
You can organize your configuration with multiple successive hal files, you just have to declare
them in the [hal] section of the ini boot file. Exemple base.hal, custom.hal, test.hal etc
At the very end you have a last hal file which is read after the GUI (axis for exemple) is loaded.
it loads the hal connections with the Pyvcp interface add-in which is designed with the xml file
Replied by gaston48 on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
hello chris,Just an idea ...
Are all your pyvcp components in custom_gvcp.hal? That's why I had very confusing reports.
You can organize your configuration with multiple successive hal files, you just have to declare
them in the [hal] section of the ini boot file. Exemple base.hal, custom.hal, test.hal etc
At the very end you have a last hal file which is read after the GUI (axis for exemple) is loaded.
it loads the hal connections with the Pyvcp interface add-in which is designed with the xml file
Please Log in or Create an account to join the conversation.
20 Feb 2021 12:17 - 20 Feb 2021 13:46 #199520
by gaston48
No,
2.7.15 Debian Wheezy is under i386 so in 32 bit because with RTAI
2.8.1 Debian 10 buster therefore under 64 bit with Prempt-RT
the 2 OS runs on the same hardware, each on an SSD hard drive
Replied by gaston48 on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
Is your 2.8.1 configuration running on the same OS and machine as the 2.7.15 configuration?
It is possible that the HAL pins take up more space on a 64-bit OS than on a 32-bit OS.
There is certainly no reason to expect any difference in behaviour here between 2.7.15 and 2.8.1 caused by LinuxCNC changes alone.
No,
2.7.15 Debian Wheezy is under i386 so in 32 bit because with RTAI
2.8.1 Debian 10 buster therefore under 64 bit with Prempt-RT
the 2 OS runs on the same hardware, each on an SSD hard drive
Last edit: 20 Feb 2021 13:46 by gaston48.
Please Log in or Create an account to join the conversation.
20 Feb 2021 13:16 #199524
by chris@cnc
Replied by chris@cnc on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
i added my simulator files. I'm also just reorganizing my config. For the test I wrote everything in pyvcp_options.hal and completely deleted gvcp. and it works too. But the order that PNCconf outputs seems to be important. and it doesn't seem to matter whether pyvcp is in the gvcp hal or not. but in order to keep things clean, i want my machine to follow this example.
HALFILE = 1-ini.hal
HALFILE = 2-io.hal
HALFILE = 3-axis.hal
HALFILE = 4-spindle.hal
POSTGUI_HALFILE = postgui_call_list.hal
in file simulator-3 the content from pyvcp_options is in custom_gvcp.hal.
ini section.
EMBED_TAB_NAME = GladeVCP
EMBED_TAB_COMMAND = halcmd loadusr -Wn gladevcp gladevcp -c gladevcp -H gvcp_call_list.hal -x {XID} gvcp-panel.ui
I would try both if one didn't work

HALFILE = 1-ini.hal
HALFILE = 2-io.hal
HALFILE = 3-axis.hal
HALFILE = 4-spindle.hal
POSTGUI_HALFILE = postgui_call_list.hal
in file simulator-3 the content from pyvcp_options is in custom_gvcp.hal.
ini section.
EMBED_TAB_NAME = GladeVCP
EMBED_TAB_COMMAND = halcmd loadusr -Wn gladevcp gladevcp -c gladevcp -H gvcp_call_list.hal -x {XID} gvcp-panel.ui
I would try both if one didn't work

Please Log in or Create an account to join the conversation.
20 Feb 2021 15:03 #199532
by andypugh
Replied by andypugh on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
Testing: With the 32-bit kernel:
With a 64-bit kernel:
So, 13 pins on the 32 bit kernel consumes 1664 bytes, and with the 64-bit kernel 1760 (creating float pins)
Creating bit pins the numbers are the same. (which makes some sense as each "pin" is really a memory pointer.
Breaking it down:
32 bits is 256 bytes for the mux function, 168 bytes for the parameters and 1144 bytes for the pins.
64 bits is 336 bytes for the mux function, 176 bytes for the parameters and 1152 bytes for the pins.
It's not a big difference, but there is a difference.
Have you considered just updating the 2.7.15 installation to 2.8.1? There is no need to change the kernel and OD just to run the latest version of LinuxCNC.
Feb 20 14:35:46 LinuxCNC-27 kernel: [665942.999739] HAL: creating pin 'set-msg-level.0.level'
Feb 20 14:35:46 LinuxCNC-27 kernel: [665942.999742] smalloc_dn: shmem available 347664
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601371] HAL: initializing component 'mux_generic'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601374] RTAPI: initing module HAL_mux_generic
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601376] RTAPI: module 'HAL_mux_generic' loaded, ID: 5
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601378] smalloc_dn: shmem available 347567
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601380] HAL: component 'mux_generic' initialized, ID = 05
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601382] smalloc_up: shmem available 347552
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601383] smalloc_up: shmem available 347504
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601385] HAL: exporting function 'mux-gen.00'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601386] smalloc_dn: shmem available 347408
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601388] HAL: creating pin 'mux-gen.00.time'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601440] smalloc_dn: shmem available 347312
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601442] HAL: creating parameter 'mux-gen.00.tmax'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601444] smalloc_dn: shmem available 347232
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601445] HAL: creating parameter 'mux-gen.00.tmax-increased'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601447] smalloc_dn: shmem available 347152
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601448] smalloc_up: shmem available 347144
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601450] HAL: creating pin 'mux-gen.00.sel-bit-00'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601451] smalloc_dn: shmem available 347048
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601453] HAL: creating pin 'mux-gen.00.sel-bit-01'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601454] smalloc_dn: shmem available 346952
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601456] HAL: creating pin 'mux-gen.00.sel-int'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601457] smalloc_dn: shmem available 346856
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601459] smalloc_up: shmem available 346832
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601460] HAL: creating pin 'mux-gen.00.in-float-00'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601461] smalloc_dn: shmem available 346736
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601463] HAL: creating pin 'mux-gen.00.in-float-01'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601464] smalloc_dn: shmem available 346640
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601466] HAL: creating pin 'mux-gen.00.in-float-02'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601467] smalloc_dn: shmem available 346544
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601469] HAL: creating pin 'mux-gen.00.in-float-03'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601470] smalloc_dn: shmem available 346448
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601472] HAL: creating pin 'mux-gen.00.suppress-no-input'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601473] smalloc_dn: shmem available 346352
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601475] HAL: creating pin 'mux-gen.00.debounce-us'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601476] smalloc_dn: shmem available 346256
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601478] HAL: creating parameter 'mux-gen.00.elapsed'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601479] smalloc_dn: shmem available 346176
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601480] HAL: creating parameter 'mux-gen.00.selected'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601482] smalloc_dn: shmem available 346096
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601483] HAL: creating pin 'mux-gen.00.out-float'
Feb 20 14:36:14 LinuxCNC-27 kernel: [665971.601485] smalloc_dn: shmem available 346000With a 64-bit kernel:
[53644.830801] HAL: creating pin 'set-msg-level.0.level'
[53644.830803] smalloc_dn: shmem available 347536
[53658.900348] HAL: initializing component 'mux_generic'
[53658.900351] RTAPI: initing module HAL_mux_generic
[53658.900352] RTAPI: module 'HAL_mux_generic' loaded, ID: 5
[53658.900354] smalloc_dn: shmem available 347423
[53658.900355] HAL: component 'mux_generic' initialized, ID = 05
[53658.900356] smalloc_up: shmem available 347392
[53658.900357] smalloc_up: shmem available 347312
[53658.900358] HAL: exporting function 'mux-gen.00'
[53658.900359] smalloc_dn: shmem available 347200
[53658.900361] HAL: creating pin 'mux-gen.00.time'
[53658.900362] smalloc_dn: shmem available 347104
[53658.900363] HAL: creating parameter 'mux-gen.00.tmax'
[53658.900364] smalloc_dn: shmem available 347024
[53658.900365] HAL: creating parameter 'mux-gen.00.tmax-increased'
[53658.900365] smalloc_dn: shmem available 346944
[53658.900366] smalloc_up: shmem available 346928
[53658.900367] HAL: creating pin 'mux-gen.00.sel-bit-00'
[53658.900368] smalloc_dn: shmem available 346832
[53658.900369] HAL: creating pin 'mux-gen.00.sel-bit-01'
[53658.900370] smalloc_dn: shmem available 346736
[53658.900371] HAL: creating pin 'mux-gen.00.sel-int'
[53658.900372] smalloc_dn: shmem available 346640
[53658.900372] smalloc_up: shmem available 346608
[53658.900373] HAL: creating pin 'mux-gen.00.in-float-00'
[53658.900374] smalloc_dn: shmem available 346512
[53658.900375] HAL: creating pin 'mux-gen.00.in-float-01'
[53658.900376] smalloc_dn: shmem available 346416
[53658.900377] HAL: creating pin 'mux-gen.00.in-float-02'
[53658.900378] smalloc_dn: shmem available 346320
[53658.900379] HAL: creating pin 'mux-gen.00.in-float-03'
[53658.900379] smalloc_dn: shmem available 346224
[53658.900380] HAL: creating pin 'mux-gen.00.suppress-no-input'
[53658.900381] smalloc_dn: shmem available 346128
[53658.900382] HAL: creating pin 'mux-gen.00.debounce-us'
[53658.900383] smalloc_dn: shmem available 346032
[53658.900384] HAL: creating parameter 'mux-gen.00.elapsed'
[53658.900385] smalloc_dn: shmem available 345952
[53658.900386] HAL: creating parameter 'mux-gen.00.selected'
[53658.900386] smalloc_dn: shmem available 345872
[53658.900387] HAL: creating pin 'mux-gen.00.out-float'
[53658.900388] smalloc_dn: shmem available 345776So, 13 pins on the 32 bit kernel consumes 1664 bytes, and with the 64-bit kernel 1760 (creating float pins)
Creating bit pins the numbers are the same. (which makes some sense as each "pin" is really a memory pointer.
Breaking it down:
32 bits is 256 bytes for the mux function, 168 bytes for the parameters and 1144 bytes for the pins.
64 bits is 336 bytes for the mux function, 176 bytes for the parameters and 1152 bytes for the pins.
It's not a big difference, but there is a difference.
Have you considered just updating the 2.7.15 installation to 2.8.1? There is no need to change the kernel and OD just to run the latest version of LinuxCNC.
Please Log in or Create an account to join the conversation.
20 Feb 2021 15:45 #199537
by andypugh
Replied by andypugh on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
I think I am losing my marbles.
I just decided that it would be a good idea to be able to set the rtapi messaging level from HAL, so set about looking at how to do that.
And found it has already been done.
Last year.
By me.
So, to check that you really are running out of memory:
At the top of the HAL file where the problem is found addThen start LinuxCNC from the command line so that you can see the debug output:
I just decided that it would be a good idea to be able to set the rtapi messaging level from HAL, so set about looking at how to do that.
And found it has already been done.
Last year.
By me.
So, to check that you really are running out of memory:
At the top of the HAL file where the problem is found add
debug 5linuxcncPlease Log in or Create an account to join the conversation.
20 Feb 2021 16:53 #199542
by gaston48
Replied by gaston48 on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
Thanks Andy for reviewing my problem
I did not need to go to 2.8 under wheezy
my concern is wheezy's obsolescence with respect to the hardware.
For example wheezy does not recognize an active usb3 cable of 10 meters, buster yes
debug 5 in the hal file or in the ini file ?
with debug 5 in the ini file :
linuxcnc -d -v
I did not need to go to 2.8 under wheezy
my concern is wheezy's obsolescence with respect to the hardware.
For example wheezy does not recognize an active usb3 cable of 10 meters, buster yes
debug 5 in the hal file or in the ini file ?
with debug 5 in the ini file :
linuxcnc -d -v
Attachments:
Please Log in or Create an account to join the conversation.
20 Feb 2021 17:04 #199544
by andypugh
In the HAL file.
Replied by andypugh on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
debug 5 in the hal file or in the ini file ?
In the HAL file.
Please Log in or Create an account to join the conversation.
20 Feb 2021 17:55 #199547
by gaston48
linuxcnc launched in the console with linuxcnc -d -v etc ...
Replied by gaston48 on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15
debug 5 in the hal file or in the ini file ?
In the HAL file.
linuxcnc launched in the console with linuxcnc -d -v etc ...
Attachments:
Please Log in or Create an account to join the conversation.
Time to create page: 0.083 seconds