changes in NML-interface?

Reinhard
Offline
Platinum Member

27 Jun 2021 12:43 #213017 by Reinhard

changes in NML-interface? was created by Reinhard

Hi,

lately i have been busy elsewhere. When I checked my application now, I found that access to NML layer no longer works.

So I compared my testprog with axis/extensions/emcmodule.cc and found little to no differences.
But when I run my testprog, I get the following errors:

At the beginning this message rises:

libnml/nml/nmlmsg.cc 93: NMLmsg: size(=5) must be atleast 16

later at polling status channel I get error at peek(), which obviously does not return EMC_STAT_TYPE

if (!check_stat(s->c)) return NULL;
   if (s->c->peek() == EMC_STAT_TYPE) {
      EMC_STAT *emcStatus = static_cast<EMC_STAT*>(s->c->get_address());
      memcpy((char*)&s->status, emcStatus, sizeof(EMC_STAT));
   }

I searched all known places, but didn't get the point.

Can someone please shine me a light about recent changes?

Please Log in or Create an account to join the conversation.

Reinhard
Offline
Platinum Member

28 Jun 2021 15:06 #213149 by Reinhard

Replied by Reinhard on topic changes in NML-interface?

I did some closer tests and it turns out, that the error is a timing issue, which is definitely new.
With former variants of LC I always got a valid response from peek.
And my app called peek/poll every 40ms

With the actual behaviour peek returns 0 and sometimes (? - unpredictably) it returns a valid response. That's not a nice behaviour for realtime communications.

When I take into account, that a human eye is capable of recognizing 24 images a second, than the delay between status calls turns out to be exactly 40ms.

Is there a way, to get faster status feedback from backend?

Please Log in or Create an account to join the conversation.

rodw
Offline
Platinum Member

28 Jun 2021 20:38 - 28 Jun 2021 20:39 #213170 by rodw

Replied by rodw on topic changes in NML-interface?

Not sure if this is relevant but from an earlier post by another user, the tool table size was increased. I think its all sent with the status so the packet becomes too big to be sent in a timely fashion... I thought there had been some changes since but its just an equate somewhere.

Last edit: 28 Jun 2021 20:39 by rodw.

Please Log in or Create an account to join the conversation.

andypugh
Offline
Moderator

29 Jun 2021 22:19 #213279 by andypugh

Replied by andypugh on topic changes in NML-interface?

I don't think you will get an answer to this question on the forum.
You _might_ get an answer on the developers mailing list.

The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

Reinhard
Offline
Platinum Member

30 Jun 2021 02:24 #213299 by Reinhard

Replied by Reinhard on topic changes in NML-interface?

Hi Rod,

thank you very much for your attention.

Yes, I already got rid of the tooltable changes. Tooltable size changes already happened when I stil was developing my app.
I noted that tooltable now has been extracted ...

What I don't understand - nml-api looks unchanged, but former peek() of status channel always (!) did return an address to an status buffer.

Actually 1 out of 10 calls the return is a valid address. 9 out of 10 times it returns 0.
The frequency of valid calls is so slow, that it makes no sense to use that api any more.

The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

rodw
Offline
Platinum Member

30 Jun 2021 06:08 #213311 by rodw

Replied by rodw on topic changes in NML-interface?

I wonder if the addition of State tags also increased the status buffer? Its been over 12 months since I looked at the interp module but I thought it was attached to the status structure. Can't remember

Please Log in or Create an account to join the conversation.

andypugh
Offline
Moderator

30 Jun 2021 07:57 #213317 by andypugh

Replied by andypugh on topic changes in NML-interface?

Reinhard wrote:
Actually 1 out of 10 calls the return is a valid address. 9 out of 10 times it returns 0.
The frequency of valid calls is so slow, that it makes no sense to use that api any more.

How does the Python interface do it?
github.com/LinuxCNC/linuxcnc/blob/master...ns/emcmodule.cc#L293
It seems to be doing pretty much what you are describing. I wonder if it is working as badly there too?

Please Log in or Create an account to join the conversation.

Reinhard
Offline
Platinum Member

30 Jun 2021 16:01 #213351 by Reinhard

Replied by Reinhard on topic changes in NML-interface?

I wonder if the addition of State tags also increased the status buffer?

Thank you Rod, but don't worry - everything is fine

It seems to be doing pretty much what you are describing.

Thank you, Andy for your attention and support!

Due to lack of understanding I followed a suboptimal template with my first try.
In the meantime I found a better one and now my access layer is straight forward and without any python burden. It looks a lot cleaner now

My testcase works fine, but for java runtime I need a library - and there I have a build problem:
I link my lib with these settings:

LC_FLAGS = -L$(abspath lc/lib) \
 -Wl,-rpath,$(abspath lc/lib) \
 -shared \
  lc/lib/liblinuxcnc.a \
  lc/lib/libnml.so.0 \
  lc/lib/liblinuxcncini.so \
  lc/lib/liblinuxcnchal.so \
  lc/lib/libtooldata.so.0 \
 -L/usr/X11R6/lib -lm -lGL

I link my testcase with the same settings, but without the "-shared" flag. That testcase works fine.
When I load the lib created with the "-shared" flag I get this error:

ibLinuxCNC.so: undefined symbol: _Z9emcFormatiPvP3CMS

I don't know, what I'm missing.

When I try to build the library without the "-shared" flag, I get these errors:

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
(.text+0x20): undefined reference to `main'

/usr/bin/ld: de_schwarzrot_system_CommandWriter.o: in function `Java_de_schwarzrot_system_CommandWriter_init':
/d/java/SR/UI4LinuxCNC/native/de_schwarzrot_system_CommandWriter.cc:87: undefined reference to `emcFormat(int, void*, CMS*)'

/usr/bin/ld: /d/java/SR/UI4LinuxCNC/native/de_schwarzrot_system_CommandWriter.cc:94: undefined reference to `emcFormat(int, void*, CMS*)'

/usr/bin/ld: de_schwarzrot_system_CommandWriter.o: in function `Java_de_schwarzrot_system_CommandWriter_setFeedOverride':
/d/java/SR/UI4LinuxCNC/native/lc/include/emc_nml.hh:548: undefined reference to `StateTag::StateTag()'
/usr/bin/ld: de_schwarzrot_system_CommandWriter.o: in function `Java_de_schwarzrot_system_CommandWriter_setRapidOverride':
/d/java/SR/UI4LinuxCNC/native/lc/include/emc_nml.hh:548: undefined reference to `StateTag::StateTag()'
/usr/bin/ld: de_schwarzrot_system_CommandWriter.o: in function `Java_de_schwarzrot_system_CommandWriter_setSpindleOverride':
/d/java/SR/UI4LinuxCNC/native/lc/include/emc_nml.hh:548: undefined reference to `StateTag::StateTag()'
collect2: error: ld returned 1 exit status
make: *** [Makefile:60: libLinuxCNC.so] Fehler 1

Please Log in or Create an account to join the conversation.

andypugh
Offline
Moderator

01 Jul 2021 22:48 #213461 by andypugh

Replied by andypugh on topic changes in NML-interface?

Reinhard wrote:

[code]ibLinuxCNC.so: undefined symbol: _Z9emcFormatiPvP3CMS

[/code]

That looks familiar, but annoyingly I have forgotten what causes nonsense symbols like that. But I have seen the same thing (not the exact same symbol, but something equally not-a-part-of-the-code) and managed to solve it, but then forgot what I did.

Please Log in or Create an account to join the conversation.

Grotius
Away
Platinum Member

02 Jul 2021 03:34 #213472 by Grotius

Replied by Grotius on topic changes in NML-interface?

One of the library's is outside the standard linux library search path.
This will add the path :
sudo ldconfig /path_to_the_lib

The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

Time to create page: 0.158 seconds