Re: [Emc-users] c++ gui module
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
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
> # 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
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
# 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
[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
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