Re: [Emc-users] c++ gui module

[theman whosoldtheworld]

Sebastian thanks a lot  Niklas sorry not understand very well  with
Lcnc I have just run some scara, delta and antrophomorphic 6ax robot ... my
first step is ok.
Now I plan to make a good non Gui rt-ethernet or some field bus rt
interface + a multiple machine control Gui interface ... qt5 gui design,
C++11 rt-interface for fielfd bus. So 1 gui interface control & multiple
non-screen Lcnc machine.

I see QUIC experiments of Sebastian (some youtube video)  fantastic ...

btk

2017-06-08 23:37 GMT+02:00 theman whosoldtheworld :

> Yes, these is a big help ... thanks
>
> bkt
>
> 2017-06-08 20:08 GMT+02:00 Sebastian Kuzminsky :
>
>> On 06/08/2017 06:44 AM, theman whosoldtheworld wrote:
>>
>>> So these is the basic struct for realize a non gui interface ... I think
>>> the emcmodule.cc file is the basic basic approach. Is my thinking
>>> correct?
>>> (these code become from emcmodule.cc)
>>>
>>> struct CIniFile {
>>> IniFile *i;
>>> };
>>>
>>> struct CStatChannel {
>>> RCS_STAT_CHANNEL *c;
>>> EMC_STAT status;
>>> };
>>>
>>> struct CCommandChannel {
>>> RCS_CMD_CHANNEL *c;
>>> RCS_STAT_CHANNEL *s;
>>> int serial;/** where find the
>>> serial number table? ... there is one? ***/
>>> };
>>>
>>
>> Yes, emcmodule.cc, and the python module named "linuxcnc" that it
>> compiles into are good for writing custom GUIs.
>>
>> Each message that goes through the NML channels is identified by a unique
>> serial number.  The serial numbers are managed by the NML infrastructure,
>> the GUI developer doesn't need to worry about it.  When the GUI sends an
>> NML message, the NML infrastructure tells the GUI the serial number of the
>> NML message, in case the GUI wants to refer to it later.  The most common
>> thing a GUI does with the serial number is to wait to hear that the message
>> was received by LinuxCNC and/or processed by LinuxCNC.
>>
>>
>> Now, if you *did* want to worry about how the serial number is handled,
>> here's the code path:
>>
>> See how emcmodule.cc:emcSendCommand() takes an NML message (in the form
>> of an RCS_CMD_MSG) and passes it to the command channel's
>> RCS_CMD_CHANNEL::write() function (line 232):
>>
>> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr
>> _intf/axis/extensions/emcmodule.cc#L231
>>
>>
>> The RCS_CMD_CHANNEL::write() function calls the underlying NML::write(),
>> passing in a *pointer* to the message's serial number:
>>
>> https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/
>> nml/cmd_msg.cc#L81
>>
>>
>> The NML::write() function calls the CMS::write() function:
>>
>> https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/
>> nml/nml.cc#L1584
>>
>>
>> CMS::write() calls a buffer-type-specific main_access() function, in this
>> case the shmem one:
>>
>> https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/
>> buffer/shmem.cc#L454
>>
>>
>> shmem's main_access() calls, on line 564, the CMS internal_access()
>> function:
>>
>> https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/
>> cms/cms_in.cc#L81
>>
>>
>> The CMS internal_access() function calls (line 188) the CMS write_raw()
>> function:
>>
>> https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/
>> cms/cms_in.cc#L1315
>>
>> The CMS write_raw() increments the CMS channel's internal serial number
>> counter (line 1355), and *finally* copies it to the serial_number pointer
>> that was passed in (line 1368).
>>
>> The message is sent, the functions return back up the call chain, and the
>> command that was passed in to emcSendCommand() has had its serial number
>> set to match the serial number of the NML message generated from it.  But
>> note, crucially how the serial number was generated by the CMS/NML/RCS
>> code, and returned to the caller.  The caller doesn't generate it.
>>
>>
>> Hope this helps.
>>
>>
>> --
>> Sebastian Kuzminsky
>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] c++ gui module

[theman whosoldtheworld]

Yes, these is a big help ... thanks

bkt

2017-06-08 20:08 GMT+02:00 Sebastian Kuzminsky :

> On 06/08/2017 06:44 AM, theman whosoldtheworld wrote:
>
>> So these is the basic struct for realize a non gui interface ... I think
>> the emcmodule.cc file is the basic basic approach. Is my thinking correct?
>> (these code become from emcmodule.cc)
>>
>> struct CIniFile {
>> IniFile *i;
>> };
>>
>> struct CStatChannel {
>> RCS_STAT_CHANNEL *c;
>> EMC_STAT status;
>> };
>>
>> struct CCommandChannel {
>> RCS_CMD_CHANNEL *c;
>> RCS_STAT_CHANNEL *s;
>> int serial;/** where find the
>> serial number table? ... there is one? ***/
>> };
>>
>
> Yes, emcmodule.cc, and the python module named "linuxcnc" that it compiles
> into are good for writing custom GUIs.
>
> Each message that goes through the NML channels is identified by a unique
> serial number.  The serial numbers are managed by the NML infrastructure,
> the GUI developer doesn't need to worry about it.  When the GUI sends an
> NML message, the NML infrastructure tells the GUI the serial number of the
> NML message, in case the GUI wants to refer to it later.  The most common
> thing a GUI does with the serial number is to wait to hear that the message
> was received by LinuxCNC and/or processed by LinuxCNC.
>
>
> Now, if you *did* want to worry about how the serial number is handled,
> here's the code path:
>
> See how emcmodule.cc:emcSendCommand() takes an NML message (in the form of
> an RCS_CMD_MSG) and passes it to the command channel's
> RCS_CMD_CHANNEL::write() function (line 232):
>
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr
> _intf/axis/extensions/emcmodule.cc#L231
>
>
> The RCS_CMD_CHANNEL::write() function calls the underlying NML::write(),
> passing in a *pointer* to the message's serial number:
>
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/
> nml/cmd_msg.cc#L81
>
>
> The NML::write() function calls the CMS::write() function:
>
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/
> nml/nml.cc#L1584
>
>
> CMS::write() calls a buffer-type-specific main_access() function, in this
> case the shmem one:
>
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/
> buffer/shmem.cc#L454
>
>
> shmem's main_access() calls, on line 564, the CMS internal_access()
> function:
>
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/
> cms/cms_in.cc#L81
>
>
> The CMS internal_access() function calls (line 188) the CMS write_raw()
> function:
>
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/
> cms/cms_in.cc#L1315
>
> The CMS write_raw() increments the CMS channel's internal serial number
> counter (line 1355), and *finally* copies it to the serial_number pointer
> that was passed in (line 1368).
>
> The message is sent, the functions return back up the call chain, and the
> command that was passed in to emcSendCommand() has had its serial number
> set to match the serial number of the NML message generated from it.  But
> note, crucially how the serial number was generated by the CMS/NML/RCS
> code, and returned to the caller.  The caller doesn't generate it.
>
>
> Hope this helps.
>
>
> --
> Sebastian Kuzminsky
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] c++ gui module

[Nicklas Karlsson]

> # Use this NML config on the computer running the realtime parts of emc2
> # in a networked system. The host address should point to the computer
> # running the GUI (although this is not critical).
> # Change the NML_FILE in emc.ini to server.nml.
> # Start emc2 normally, and then run the GUI client.
> 
> so I can run in rt-pc a non gui Lcnc session, than in other pc using
> server.nml  can run axis gui session for example?
> And these is not well tested  ok.

This is what I plan to do in next step as soon as I am done with my driver 
cards, as is now it mostly about figure out practical things for assembly. I 
got my first machine almost up and running, one of the axis is hard to move and 
need some lubrication.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] c++ gui module

[Sebastian Kuzminsky]

On 06/08/2017 06:44 AM, theman whosoldtheworld wrote:

So these is the basic struct for realize a non gui interface ... I think
the emcmodule.cc file is the basic basic approach. Is my thinking correct?
(these code become from emcmodule.cc)

struct CIniFile {
IniFile *i;
};

struct CStatChannel {
RCS_STAT_CHANNEL *c;
EMC_STAT status;
};

struct CCommandChannel {
RCS_CMD_CHANNEL *c;
RCS_STAT_CHANNEL *s;
int serial;/** where find the
serial number table? ... there is one? ***/
};


Yes, emcmodule.cc, and the python module named "linuxcnc" that it 
compiles into are good for writing custom GUIs.


Each message that goes through the NML channels is identified by a 
unique serial number.  The serial numbers are managed by the NML 
infrastructure, the GUI developer doesn't need to worry about it.  When 
the GUI sends an NML message, the NML infrastructure tells the GUI the 
serial number of the NML message, in case the GUI wants to refer to it 
later.  The most common thing a GUI does with the serial number is to 
wait to hear that the message was received by LinuxCNC and/or processed 
by LinuxCNC.



Now, if you *did* want to worry about how the serial number is handled, 
here's the code path:


See how emcmodule.cc:emcSendCommand() takes an NML message (in the form 
of an RCS_CMD_MSG) and passes it to the command channel's 
RCS_CMD_CHANNEL::write() function (line 232):


https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr_intf/axis/extensions/emcmodule.cc#L231


The RCS_CMD_CHANNEL::write() function calls the underlying NML::write(), 
passing in a *pointer* to the message's serial number:


https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/nml/cmd_msg.cc#L81


The NML::write() function calls the CMS::write() function:

https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/nml/nml.cc#L1584


CMS::write() calls a buffer-type-specific main_access() function, in 
this case the shmem one:


https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/buffer/shmem.cc#L454


shmem's main_access() calls, on line 564, the CMS internal_access() 
function:


https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/cms/cms_in.cc#L81


The CMS internal_access() function calls (line 188) the CMS write_raw() 
function:


https://github.com/LinuxCNC/linuxcnc/blob/master/src/libnml/cms/cms_in.cc#L1315

The CMS write_raw() increments the CMS channel's internal serial number 
counter (line 1355), and *finally* copies it to the serial_number 
pointer that was passed in (line 1368).


The message is sent, the functions return back up the call chain, and 
the command that was passed in to emcSendCommand() has had its serial 
number set to match the serial number of the NML message generated from 
it.  But note, crucially how the serial number was generated by the 
CMS/NML/RCS code, and returned to the caller.  The caller doesn't 
generate it.



Hope this helps.


--
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] c++ gui module

[theman whosoldtheworld]

# Use this NML config on the computer running the realtime parts of emc2
# in a networked system. The host address should point to the computer
# running the GUI (although this is not critical).
# Change the NML_FILE in emc.ini to server.nml.
# Start emc2 normally, and then run the GUI client.

so I can run in rt-pc a non gui Lcnc session, than in other pc using
server.nml  can run axis gui session for example?
And these is not well tested  ok.

In fact it's not a very interesting thing 
it's more interesting to pass the cmd / stat / error signals of a non-gui
session on fieldbus with rt & user-space capability to interface with a
master gui  this Is a better operation.

So these is the basic struct for realize a non gui interface ... I think
the emcmodule.cc file is the basic basic approach. Is my thinking correct?
(these code become from emcmodule.cc)

struct CIniFile {
IniFile *i;
};

struct CStatChannel {
RCS_STAT_CHANNEL *c;
EMC_STAT status;
};

struct CCommandChannel {
RCS_CMD_CHANNEL *c;
RCS_STAT_CHANNEL *s;
int serial;/** where find the
serial number table? ... there is one? ***/
};

struct CErrorChannel {
NML *c;
};

bkt

2017-06-08 13:58 GMT+02:00 Jeff Epler :

> [on editing .nml files and using "REMOTE" shared memory segments]
>
> Hardly anyone does this sort of thing in practice, so changing the .nml
> file in this way is "untested at best".  You may end up debugging code
> you're not really interested in debugging.  However, in our master
> branch, tests/linuxcncrsh-tcp does use a variant of linuxcnc.nml called
> tcp.nml; we do do basic testing over the loopback interface that the
> nml-over-tcp interface is not totally broken.
>
> Jeff
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] c++ gui module

[Jeff Epler]

[on editing .nml files and using "REMOTE" shared memory segments]

Hardly anyone does this sort of thing in practice, so changing the .nml
file in this way is "untested at best".  You may end up debugging code
you're not really interested in debugging.  However, in our master
branch, tests/linuxcncrsh-tcp does use a variant of linuxcnc.nml called
tcp.nml; we do do basic testing over the loopback interface that the
nml-over-tcp interface is not totally broken.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] c++ gui module

[theman whosoldtheworld]

Thanks Jeff.

so I can modify linuxcnc.nml (37-38-39 row) in these manner:

P myUI  emcCommand  LOCAL   localhost   W   0
10.00   10
P myUI  emcStatus   LOCAL   localhost   R   0
10.00   10
P myUI  emcError  LOCAL   localhost   R
0   10.00   10

than use the parameter in these way?

> RCS_STAT_CHANNEL *c =
> new RCS_STAT_CHANNEL(emcFormat, "emcStatus", "myUI", file)

Anyway, if I wanted to send a stat/cmd/err signal to a remote server, would
it be correct to add these three lines to the linuxcnc.nml file?

P myUI  emcCommand  REMOTE   192.105.0.5   W   0
10.00   10
P myUI  emcStatus   REMOTE   192.105.0.5   R
0   10.00   10
P myUI  emcError REMOTE   192.105.0.5   R
0   10.00   10

and if I add a rt-ethernet line can you share between the two pc SHMEM in
some way (ex. using reflective memory)?
The purpose is to have rt copy of the messages so that they have exact copy
of the results on an external pc  for example to replicate the graphic
portion of vismac on multiple pc at the same time  or to send and
receive rt signals from Multiple workstations at the same time. The idea of
​​sharing SHMEM is because I think it's quicker to have data in this way
... but it might also be a bad idea for latency times.

Correct me if I'm wrong but my configuration example with REMOTE host sends
the signals in user-space, not in rt-space. Did I understand correctly or
incorrectly?

bkt

2017-06-07 13:54 GMT+02:00 Jeff Epler :

> > RCS_STAT_CHANNEL *c =
> > new RCS_STAT_CHANNEL(emcFormat, "emcStatus", "xemc", file);
>
> The parameter "xemc" here is a mostly-meaningless string that needs
> to match the "name" column of an "emcStatus" line in the
> linuxcnc.nml file.  You can think of it as just meaning "the
> standard name for a UI process".
>
> Jeff
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users