Machinekitclient, remote stdout shows up as error dialogs

40 views
Skip to first unread message

fritz

unread,
Mar 13, 2019, 7:31:34 PM3/13/19
to machi...@googlegroups.com
I am using a BBB running the latest MK with Cetus.

My ini has DEBUG=0

When I connect with MachinkitClient to the session, a bunch of stuff
that was  being printed to sdout

and also to the the log during my tinkering phase comes up as error
dialogs like in the attached screenshot.

Any suggestions as to why?


My config is at https://github.com/coldelectrons/mk-lowrider2

The log from one such session in /var/log/linuxcnc.log:

Mar 13 22:16:48 lowriderbone msgd:0: startup pid=14423 flavor=rt-preempt
rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 6.3.0 20170516 
version=v0.1~-----~1dfa004
Mar 13 22:16:48 lowriderbone msgd:0: ØMQ=4.2.1 czmq=4.0.2 protobuf=3.0.0
atomics=gcc intrinsics    libwebsockets=2.0.3
Mar 13 22:16:48 lowriderbone msgd:0: configured: sha=1dfa004
Mar 13 22:16:48 lowriderbone msgd:0: built:      Jan 23 2019 10:18:33
sha=1dfa004
Mar 13 22:16:48 lowriderbone msgd:0: register_stuff: actual hostname as
announced by avahi='lowriderbone.local'
Mar 13 22:16:48 lowriderbone msgd:0: zeroconf: registering: 'Log service
on lowriderbone.local pid 14423'
Mar 13 22:16:49 lowriderbone msgd:0: zeroconf: registered 'Log service
on lowriderbone.local pid 14423' _machinekit._tcp 49152 TXT
"uuid=52fba462-bda9-46a5-89f0-21996d5170ff"
"instance=b1da9886-45dd-11e9-8743-c8a030ad5fb2" "service=log"
"dsn=tcp://lowriderbone.local:49152"
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt memmapped gpio
port 2 to 0xb6f36000, oe: 0xb6f36134, set: 0xb6f36194, clr: 0xb6f36190
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt pin 7 maps to pin
2-2, mode 85
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt pin 8 maps to pin
2-3, mode 85
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt pin 9 maps to pin
2-5, mode 85
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt pin 10 maps to pin
2-4, mode 85
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt memmapped gpio
port 0 to 0xb6f34000, oe: 0xb6f34134, set: 0xb6f34194, clr: 0xb6f34190
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt pin 17 maps to pin
0-27, mode 85
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt pin 11 maps to pin
0-30, mode 85
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt pin 13 maps to pin
0-31, mode 85
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt memmapped gpio
port 1 to 0xb6f32000, oe: 0xb6f32134, set: 0xb6f32194, clr: 0xb6f32190
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt memmapped gpio
port 3 to 0xb6f30000, oe: 0xb6f30134, set: 0xb6f30194, clr: 0xb6f30190
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt prussdrv_init
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt prussdrv_open
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt prussdrv_pruintc_init
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt prussdrv_map_prumem
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt PRU data ram mapped
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt num_pwmgens : 0
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt num_stepgens: 6
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt num_encoders: 0
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt Init pwm
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt Init stepgen
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt hpg_stepgen_init
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt Init encoder
Mar 13 22:16:50 lowriderbone msgd:0: hal_lib:14428:rt creating ladder-state
Mar 13 22:16:51 lowriderbone msgd:0: hal_lib:14450:user INFO
CLASSICLADDER-   No ladder GUI requested-Realtime runs till HAL closes.

Screenshot from 2019-03-13 18-17-42.png

schoo...@gmail.com

unread,
Mar 14, 2019, 5:48:02 AM3/14/19
to machi...@googlegroups.com
This is in hand.

A long time ago, possibly in linuxcnc, someone set the behaviour of the
print functions to be contrary to what was expected,
instead of fixing them so that they didn't spew unwanted info.

A recent commit changed this because some info was not being printed
when it should be, but with knock on as you found.

The behaviour will be reverted shortly and the print issue re-visited later.

regards
Reply all
Reply to author
Forward
0 new messages