LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15

More
5 years 8 months ago #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.

Please Log in to join the conversation.

More
5 years 8 months ago #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.

Please Log in to join the conversation.

More
5 years 8 months ago #199517 by gaston48
Replied by gaston48 on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15

chris@cnc wrote: Just an idea ...
Are all your pyvcp components in custom_gvcp.hal? That's why I had very confusing reports.

hello chris,
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 to join the conversation.

More
5 years 8 months ago #199520 by gaston48
Replied by gaston48 on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15

andypugh wrote: 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

Please Log in to join the conversation.

More
5 years 8 months ago #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


Please Log in to join the conversation.

More
5 years 8 months ago #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:
Code:
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 346000

With a 64-bit kernel:

Code:
[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 345776

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.

Please Log in to join the conversation.

More
5 years 8 months ago #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 add
Code:
debug 5
Then start LinuxCNC from the command line so that you can see the debug output:
Code:
linuxcnc

Please Log in to join the conversation.

More
5 years 8 months ago #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

Attachment not found

Please Log in to join the conversation.

More
5 years 8 months ago #199544 by andypugh
Replied by andypugh on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15

gaston48 wrote: debug 5 in the hal file or in the ini file ?


In the HAL file.

Please Log in to join the conversation.

More
5 years 8 months ago #199547 by gaston48
Replied by gaston48 on topic LinuxCNC 2.8.1 configuration doesn't run after upgrading from 2.7.15

andypugh wrote:

gaston48 wrote: 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 ...


Attachment not found

Please Log in to join the conversation.

Time to create page: 0.101 seconds
Powered by Kunena Forum