[Emc-users] c++ gui module

[theman whosoldtheworld]

hi,

into /home/linuxcnc-dev/src/emc/usr_intf/axis/extension ... i read these:

static int Stat_init(pyStatChannel *self, PyObject *a, PyObject *k) {
char *file = get_nmlfile();
if(file == NULL) return -1;

RCS_STAT_CHANNEL *c =
new RCS_STAT_CHANNEL(emcFormat, "emcStatus", "xemc", file);
if(!c) {
PyErr_Format( error, "new RCS_STAT_CHANNEL failed");
return -1;
}

self->c = c;
return 0;
}

so write a c++ interface using RCS_STAT_CHANNEL(emcFormat, "emcStatus",
"xemc", file) with "xemc" param is still valid option i suppose. I'm in
wrong?

bkt

[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

[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.0 0 10
P myUI emcStatus LOCAL localhost R 0
10.0 0 10
P myUI emcError LOCAL localhost R
0 10.0 0 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.0 0 10
P myUI emcStatus REMOTE 192.105.0.5 R
0 10.0 0 10
P myUI emcError REMOTE 192.105.0.5 R
0 10.0 0 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 <***@unpythonic.net>:

> > 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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[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

[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 <***@unpythonic.net>:

> [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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[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

[theman whosoldtheworld]

Yes, these is a big help ... thanks

bkt

2017-06-08 20:08 GMT+02:00 Sebastian Kuzminsky <***@highlab.com>:

> 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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[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 <***@gmail.com>:

> Yes, these is a big help ... thanks
>
> bkt
>
> 2017-06-08 20:08 GMT+02:00 Sebastian Kuzminsky <***@highlab.com>:
>
>> 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-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>
>

[Nicklas Karlsson]

> 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 ...

If you work with hardware SPI might be a solution, it is very common on micro controllers, fast and cheap but with limitations. I have seen Ethercat modules with SPI interface. I think there might other field bus devices with SPI but are not sure but it make little sense with SPI interface for field buses with UART and CAN since these are available inside micro controllers.

For non real time I guess ordinary ethernet make sense. I think there are both WiFi and Ethernet with SPI interfaces available.

[theman whosoldtheworld]

... thanks for your advice ... but there are 3-4 solution for these things
....
But at present I am more concerned with understanding the use of various
Lcnc files than any other.
For general information, QT5.9 has been released in recent weeks with
security rt operations certified to European standards ...
so that all realtime traffic can be separated from the gui in the same
program / app without too little trouble, simply by activating a realtime
thread As if it were a normal thread and certified capability.
At this point ardware becomes the smallest problem, since it is qt itself
to indicate what kind of hardware and cpu ....
the qt have canbus owner also on linux (ehternet/rt-ethernet, modbus,
canbus, dbus). I guess
it will not be so impossible to integrate another user-space bus or less
(in the case of rt-time it will have to be a certified bus at this point
... or the classic rt-ethernet already included between buses qt).

bkt

2017-06-09 22:35 GMT+02:00 Nicklas Karlsson <***@gmail.com>:

> > 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 ...
>
> If you work with hardware SPI might be a solution, it is very common on
> micro controllers, fast and cheap but with limitations. I have seen
> Ethercat modules with SPI interface. I think there might other field bus
> devices with SPI but are not sure but it make little sense with SPI
> interface for field buses with UART and CAN since these are available
> inside micro controllers.
>
> For non real time I guess ordinary ethernet make sense. I think there are
> both WiFi and Ethernet with SPI interfaces available.
>
> ------------------------------------------------------------
> ------------------
> 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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[theman whosoldtheworld]

sorry : certifiable instad certified .... terms errore.

btk

2017-06-10 22:48 GMT+02:00 theman whosoldtheworld <***@gmail.com>:

> ... thanks for your advice ... but there are 3-4 solution for these things
> ....
> But at present I am more concerned with understanding the use of various
> Lcnc files than any other.
> For general information, QT5.9 has been released in recent weeks with
> security rt operations certified to European standards ...
> so that all realtime traffic can be separated from the gui in the same
> program / app without too little trouble, simply by activating a realtime
> thread As if it were a normal thread and certified capability.
> At this point ardware becomes the smallest problem, since it is qt itself
> to indicate what kind of hardware and cpu ....
> the qt have canbus owner also on linux (ehternet/rt-ethernet, modbus,
> canbus, dbus). I guess
> it will not be so impossible to integrate another user-space bus or less
> (in the case of rt-time it will have to be a certified bus at this point
> ... or the classic rt-ethernet already included between buses qt).
>
> bkt
>
> 2017-06-09 22:35 GMT+02:00 Nicklas Karlsson <***@gmail.com>
> :
>
>> > 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 ...
>>
>> If you work with hardware SPI might be a solution, it is very common on
>> micro controllers, fast and cheap but with limitations. I have seen
>> Ethercat modules with SPI interface. I think there might other field bus
>> devices with SPI but are not sure but it make little sense with SPI
>> interface for field buses with UART and CAN since these are available
>> inside micro controllers.
>>
>> For non real time I guess ordinary ethernet make sense. I think there are
>> both WiFi and Ethernet with SPI interfaces available.
>>
>> ------------------------------------------------------------
>> ------------------
>> 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-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>
>

[Nicklas Karlsson]

On Sat, 10 Jun 2017 22:48:47 +0200
theman whosoldtheworld <***@gmail.com> wrote:

> ... thanks for your advice ... but there are 3-4 solution for these things
> ....
> But at present I am more concerned with understanding the use of various
> Lcnc files than any other.
> For general information, QT5.9 has been released in recent weeks with
> security rt operations certified to European standards ...

So what security rt operation certified to European standards mean? Is it useful for a servo loop? Or an ATM machine?

[Nicklas Karlsson]

On Sat, 10 Jun 2017 22:48:47 +0200
theman whosoldtheworld <***@gmail.com> wrote:

> ... thanks for your advice ... but there are 3-4 solution for these things
> ....
> For general information, QT5.9 has been released in recent weeks with
> security rt operations certified to European standards ...
> so that all realtime traffic can be separated from the gui in the same
> program / app without too little trouble, simply by activating a realtime
> thread As if it were a normal thread and certified capability.

I use use a linux kernel with a real time patch and I am in doubt QT could do little about this kernel thread, QT must rely on some kind of operating system support otherwise it run as any other application.

[Nicklas Karlsson]

On Sat, 10 Jun 2017 22:48:47 +0200
theman whosoldtheworld <***@gmail.com> wrote:

> ... thanks for your advice ... but there are 3-4 solution for these things
> ....
> But at present I am more concerned with understanding the use of various
> Lcnc files than any other.

The lcnc files are a little bit hard to understand. The *.hal files are almost like netlists used for schematics. It make a lot more sense to visualize the configuration in schematic.

There are some old almost working example with geda gschem, whenever I have a few I will try to get the script to work. I also heard something about rockhopper, it is also vizualized graphically although this was some kind of web based interface, html have limitations then it come to user interfaces and usually have a second or so delay whenever something is pressed. Graphical representation with gschem should be simple, script is currently in python while most other output from gschem via gnetlist is in scheme language.


I am fully with you then it come to split application in non real time GUI and real time. And at least partly with you then it come C++ and do not like python programming language but use whatever is available or have been used before.


Then it come to GUI I like the glade interface designer and automatic connection of callback functions. Automatic connection of callback functions are available in C but not C++ and for python I do not know.

[theman whosoldtheworld]

see these:
https://blog.qt.io/blog/2017/05/17/integrity-rtos-support-qt-5-9-lts/ ...
As you said, me too I try is little bit hard use qt c++ program instead
Lcnc c/c++ for driving servos machines .... but it promise rtos realtime so
sometings is for certain possible ... any how the goal for new qt5.9 rt is
automotive industries ... not robotics or chips machines ...the common
denominator is sending realtime command signals and receiving them, a
little logical work to make the signal available and allow the operator to
see or send these signals. Taking the sums I think is the first test to
pave the way for the qt to the future automatic driving machines.

my intention is use qt5.9 to interface a gui using a modern opensource
industrial bus, with other electronics devices and some pc with Lcnc
without gui.I'm not going to use the industrial buses to drive the servo
... I find it safer to use the command and safety buses (even in the servo)
and use traditional piloting for the positioning and the feedbak ... so two
different line to the servo on two totally different channels, analogue for
driving, digital for safety and functional. It's like having two dogs who
are guarding one against each other.

The project would be: to create an rt component that starts as if it were a
gui at opening lcnc, the component starts a server connection of some
industrial bus and waits for queries from slaves or slaves, as for example
some commands / requests may arrive From a plc of security; Create a gui in
qt on remote pc having its main thread, secondary ones of service and then
one or more thread rt for communication to pc lcnc via industrial bus rt or
other devices (eg plc security).

I've already relayed this thing with modbus as a test ... but modbus, even
turning very fast with new technologies, even over 115000, always sends 16
bits at a time ... for good remote control Of Lcnc serve at least 48 bits
for the on / off commands + others to have floats .... so a fast and large
bus is what you need ... believe that's why Sebastian has used QUIC.

I'm happy to chat with you about this.

bkt


2017-06-11 17:21 GMT+02:00 Nicklas Karlsson <***@gmail.com>:

> On Sat, 10 Jun 2017 22:48:47 +0200
> theman whosoldtheworld <***@gmail.com> wrote:
>
> > ... thanks for your advice ... but there are 3-4 solution for these
> things
> > ....
> > But at present I am more concerned with understanding the use of various
> > Lcnc files than any other.
>
> The lcnc files are a little bit hard to understand. The *.hal files are
> almost like netlists used for schematics. It make a lot more sense to
> visualize the configuration in schematic.
>
> There are some old almost working example with geda gschem, whenever I
> have a few I will try to get the script to work. I also heard something
> about rockhopper, it is also vizualized graphically although this was some
> kind of web based interface, html have limitations then it come to user
> interfaces and usually have a second or so delay whenever something is
> pressed. Graphical representation with gschem should be simple, script is
> currently in python while most other output from gschem via gnetlist is in
> scheme language.
>
>
> I am fully with you then it come to split application in non real time GUI
> and real time. And at least partly with you then it come C++ and do not
> like python programming language but use whatever is available or have been
> used before.
>
>
> Then it come to GUI I like the glade interface designer and automatic
> connection of callback functions. Automatic connection of callback
> functions are available in C but not C++ and for python I do not know.
>
> ------------------------------------------------------------
> ------------------
> 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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[Nicklas Karlsson]

I read and it mostly seems to be about security. Realtime scheduling make sense for every task which is periodic or may be treated as a periodic task. A really good example is a serial receive buffer since data will be lost if not handled periodically.

GUI I usually treat as periodic task with a dead time of about 20-50 milliseconds even though it seldoms happens. Video I guess is about 30-50 milliseconds. Servo loop is around 1 milliseconds and even though little computational power is required ordinary computer seems to have problem with this.

They mention something about support for a real time operating system and for linuxcnc the kernel RT patch is used or RTAI. On a micro controller I most often use an interrupt with suitable priority, software is most often simple with only a few well known interrupts so most often it works really well.


The most useful scheduling schemes are Earliest Dead Line first https://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling and for static priority rate monotonic which may be implemented with nested interrupts with priority https://sv.wikipedia.org/wiki/Rate-monoton_schemal%C3%A4ggning

Dead line should be equal to periodic which most often is possible. For video with a dubble buffer, for serial receive buffer interrupt is triggered then buffer is half full, ... It is commmon to talk about jitter which make som sense but for properly implented EDF or rate monotonic scheduling jitter within period make no difference.


Here http://linuxcnc.org/docs/2.6/html/code/Code_Notes.html at "4. Architecture overview" is probably what you need to understand how the different parts of linuxcnc is put together. The real time part I want to put on simple computer and the GUI on an ordinary computer since they are readily available cheap. There are two advantages: I want to keep real time communication local and remove real time demand from ordinary computer.


Regards Nicklas Karlsson



On Sun, 11 Jun 2017 23:19:27 +0200
theman whosoldtheworld <***@gmail.com> wrote:

> see these:
> https://blog.qt.io/blog/2017/05/17/integrity-rtos-support-qt-5-9-lts/ ...
> As you said, me too I try is little bit hard use qt c++ program instead
> Lcnc c/c++ for driving servos machines .... but it promise rtos realtime so
> sometings is for certain possible ... any how the goal for new qt5.9 rt is
> automotive industries ... not robotics or chips machines ...the common
> denominator is sending realtime command signals and receiving them, a
> little logical work to make the signal available and allow the operator to
> see or send these signals. Taking the sums I think is the first test to
> pave the way for the qt to the future automatic driving machines.
>
> my intention is use qt5.9 to interface a gui using a modern opensource
> industrial bus, with other electronics devices and some pc with Lcnc
> without gui.I'm not going to use the industrial buses to drive the servo
> ... I find it safer to use the command and safety buses (even in the servo)
> and use traditional piloting for the positioning and the feedbak ... so two
> different line to the servo on two totally different channels, analogue for
> driving, digital for safety and functional. It's like having two dogs who
> are guarding one against each other.
>
> The project would be: to create an rt component that starts as if it were a
> gui at opening lcnc, the component starts a server connection of some
> industrial bus and waits for queries from slaves or slaves, as for example
> some commands / requests may arrive From a plc of security; Create a gui in
> qt on remote pc having its main thread, secondary ones of service and then
> one or more thread rt for communication to pc lcnc via industrial bus rt or
> other devices (eg plc security).
>
> I've already relayed this thing with modbus as a test ... but modbus, even
> turning very fast with new technologies, even over 115000, always sends 16
> bits at a time ... for good remote control Of Lcnc serve at least 48 bits
> for the on / off commands + others to have floats .... so a fast and large
> bus is what you need ... believe that's why Sebastian has used QUIC.
>
> I'm happy to chat with you about this.
>
> bkt
>
>
> 2017-06-11 17:21 GMT+02:00 Nicklas Karlsson <***@gmail.com>:
>
> > On Sat, 10 Jun 2017 22:48:47 +0200
> > theman whosoldtheworld <***@gmail.com> wrote:
> >
> > > ... thanks for your advice ... but there are 3-4 solution for these
> > things
> > > ....
> > > But at present I am more concerned with understanding the use of various
> > > Lcnc files than any other.
> >
> > The lcnc files are a little bit hard to understand. The *.hal files are
> > almost like netlists used for schematics. It make a lot more sense to
> > visualize the configuration in schematic.
> >
> > There are some old almost working example with geda gschem, whenever I
> > have a few I will try to get the script to work. I also heard something
> > about rockhopper, it is also vizualized graphically although this was some
> > kind of web based interface, html have limitations then it come to user
> > interfaces and usually have a second or so delay whenever something is
> > pressed. Graphical representation with gschem should be simple, script is
> > currently in python while most other output from gschem via gnetlist is in
> > scheme language.
> >
> >
> > I am fully with you then it come to split application in non real time GUI
> > and real time. And at least partly with you then it come C++ and do not
> > like python programming language but use whatever is available or have been
> > used before.
> >
> >
> > Then it come to GUI I like the glade interface designer and automatic
> > connection of callback functions. Automatic connection of callback
> > functions are available in C but not C++ and for python I do not know.
> >
> > ------------------------------------------------------------
> > ------------------
> > 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-***@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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[theman whosoldtheworld]

thanks..

bkt

2017-06-12 0:47 GMT+02:00 Nicklas Karlsson <***@gmail.com>:

> I read and it mostly seems to be about security. Realtime scheduling make
> sense for every task which is periodic or may be treated as a periodic
> task. A really good example is a serial receive buffer since data will be
> lost if not handled periodically.
>
> GUI I usually treat as periodic task with a dead time of about 20-50
> milliseconds even though it seldoms happens. Video I guess is about 30-50
> milliseconds. Servo loop is around 1 milliseconds and even though little
> computational power is required ordinary computer seems to have problem
> with this.
>
> They mention something about support for a real time operating system and
> for linuxcnc the kernel RT patch is used or RTAI. On a micro controller I
> most often use an interrupt with suitable priority, software is most often
> simple with only a few well known interrupts so most often it works really
> well.
>
>
> The most useful scheduling schemes are Earliest Dead Line first
> https://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling and for
> static priority rate monotonic which may be implemented with nested
> interrupts with priority https://sv.wikipedia.org/wiki/
> Rate-monoton_schemal%C3%A4ggning
>
> Dead line should be equal to periodic which most often is possible. For
> video with a dubble buffer, for serial receive buffer interrupt is
> triggered then buffer is half full, ... It is commmon to talk about jitter
> which make som sense but for properly implented EDF or rate monotonic
> scheduling jitter within period make no difference.
>
>
> Here http://linuxcnc.org/docs/2.6/html/code/Code_Notes.html at "4.
> Architecture overview" is probably what you need to understand how the
> different parts of linuxcnc is put together. The real time part I want to
> put on simple computer and the GUI on an ordinary computer since they are
> readily available cheap. There are two advantages: I want to keep real time
> communication local and remove real time demand from ordinary computer.
>
>
> Regards Nicklas Karlsson
>
>
>
> On Sun, 11 Jun 2017 23:19:27 +0200
> theman whosoldtheworld <***@gmail.com> wrote:
>
> > see these:
> > https://blog.qt.io/blog/2017/05/17/integrity-rtos-support-qt-5-9-lts/
> ...
> > As you said, me too I try is little bit hard use qt c++ program instead
> > Lcnc c/c++ for driving servos machines .... but it promise rtos realtime
> so
> > sometings is for certain possible ... any how the goal for new qt5.9 rt
> is
> > automotive industries ... not robotics or chips machines ...the common
> > denominator is sending realtime command signals and receiving them, a
> > little logical work to make the signal available and allow the operator
> to
> > see or send these signals. Taking the sums I think is the first test to
> > pave the way for the qt to the future automatic driving machines.
> >
> > my intention is use qt5.9 to interface a gui using a modern opensource
> > industrial bus, with other electronics devices and some pc with Lcnc
> > without gui.I'm not going to use the industrial buses to drive the servo
> > ... I find it safer to use the command and safety buses (even in the
> servo)
> > and use traditional piloting for the positioning and the feedbak ... so
> two
> > different line to the servo on two totally different channels, analogue
> for
> > driving, digital for safety and functional. It's like having two dogs who
> > are guarding one against each other.
> >
> > The project would be: to create an rt component that starts as if it
> were a
> > gui at opening lcnc, the component starts a server connection of some
> > industrial bus and waits for queries from slaves or slaves, as for
> example
> > some commands / requests may arrive From a plc of security; Create a gui
> in
> > qt on remote pc having its main thread, secondary ones of service and
> then
> > one or more thread rt for communication to pc lcnc via industrial bus rt
> or
> > other devices (eg plc security).
> >
> > I've already relayed this thing with modbus as a test ... but modbus,
> even
> > turning very fast with new technologies, even over 115000, always sends
> 16
> > bits at a time ... for good remote control Of Lcnc serve at least 48 bits
> > for the on / off commands + others to have floats .... so a fast and
> large
> > bus is what you need ... believe that's why Sebastian has used QUIC.
> >
> > I'm happy to chat with you about this.
> >
> > bkt
> >
> >
> > 2017-06-11 17:21 GMT+02:00 Nicklas Karlsson <
> ***@gmail.com>:
> >
> > > On Sat, 10 Jun 2017 22:48:47 +0200
> > > theman whosoldtheworld <***@gmail.com> wrote:
> > >
> > > > ... thanks for your advice ... but there are 3-4 solution for these
> > > things
> > > > ....
> > > > But at present I am more concerned with understanding the use of
> various
> > > > Lcnc files than any other.
> > >
> > > The lcnc files are a little bit hard to understand. The *.hal files are
> > > almost like netlists used for schematics. It make a lot more sense to
> > > visualize the configuration in schematic.
> > >
> > > There are some old almost working example with geda gschem, whenever I
> > > have a few I will try to get the script to work. I also heard something
> > > about rockhopper, it is also vizualized graphically although this was
> some
> > > kind of web based interface, html have limitations then it come to user
> > > interfaces and usually have a second or so delay whenever something is
> > > pressed. Graphical representation with gschem should be simple, script
> is
> > > currently in python while most other output from gschem via gnetlist
> is in
> > > scheme language.
> > >
> > >
> > > I am fully with you then it come to split application in non real time
> GUI
> > > and real time. And at least partly with you then it come C++ and do not
> > > like python programming language but use whatever is available or have
> been
> > > used before.
> > >
> > >
> > > Then it come to GUI I like the glade interface designer and automatic
> > > connection of callback functions. Automatic connection of callback
> > > functions are available in C but not C++ and for python I do not know.
> > >
> > > ------------------------------------------------------------
> > > ------------------
> > > 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-***@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-***@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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[andy pugh]

On 11 June 2017 at 22:19, theman whosoldtheworld <***@gmail.com>
wrote:

> As you said, me too I try is little bit hard use qt c++ program instead
> Lcnc c/c++ for driving servos machines
>

Not 100% relevant to this discussion, but related: There has been some work
done on integrating QT with LinuxCNC.
See, for example, this feature branch:
https://github.com/LinuxCNC/linuxcnc/tree/qt5vcp_master
(I know nothing about this branch other than that it exists, though)


--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

[theman whosoldtheworld]

I have already seen the repository, it can be a way to get to know better ....
but pyqt is not qt c++ ... it does not change much to use py or pyqt
... said this is a great job.

Any how my intention is not to make a classic gui for Lcnc local machine ...
I find thay in local pc Lcnc is perfect as is it.

I think is possible it can do something for the group of machines ...
put on each machine a graphical interface is not my purpose.


bkt


2017-06-12 11:26 GMT+02:00 andy pugh <***@gmail.com>:

> On 11 June 2017 at 22:19, theman whosoldtheworld <***@gmail.com>
> wrote:
>
> > As you said, me too I try is little bit hard use qt c++ program instead
> > Lcnc c/c++ for driving servos machines
> >
>
> Not 100% relevant to this discussion, but related: There has been some work
> done on integrating QT with LinuxCNC.
> See, for example, this feature branch:
> https://github.com/LinuxCNC/linuxcnc/tree/qt5vcp_master
> (I know nothing about this branch other than that it exists, though)
>
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is designed
> for the especial use of mechanical geniuses, daredevils and lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
> ------------------------------------------------------------
> ------------------
> 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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[Nicklas Karlsson]

On Mon, 12 Jun 2017 18:22:07 +0200
theman whosoldtheworld <***@gmail.com> wrote:

> I have already seen the repository, it can be a way to get to know better ....
> but pyqt is not qt c++ ... it does not change much to use py or pyqt
> ... said this is a great job.
>
> Any how my intention is not to make a classic gui for Lcnc local machine ...
> I find thay in local pc Lcnc is perfect as is it.
>
> I think is possible it can do something for the group of machines ...
> put on each machine a graphical interface is not my purpose.

I am with you for group of machines. I have small engraver on or actually below the table and to run in remotely from ordinary PC make sense. I am pretty sure there are many other cases there it make sense to control several machines from one display, robots?

[theman whosoldtheworld]

@Niklas robots is the first candidate in my case .... Also because with
linuxcnc more than 9 axes you can not drive ...

@Chris ... real Good Job.

bkt

2017-06-12 20:09 GMT+02:00 Nicklas Karlsson <***@gmail.com>:

> On Mon, 12 Jun 2017 18:22:07 +0200
> theman whosoldtheworld <***@gmail.com> wrote:
>
> > I have already seen the repository, it can be a way to get to know
> better ....
> > but pyqt is not qt c++ ... it does not change much to use py or pyqt
> > ... said this is a great job.
> >
> > Any how my intention is not to make a classic gui for Lcnc local machine
> ...
> > I find thay in local pc Lcnc is perfect as is it.
> >
> > I think is possible it can do something for the group of machines ...
> > put on each machine a graphical interface is not my purpose.
>
> I am with you for group of machines. I have small engraver on or actually
> below the table and to run in remotely from ordinary PC make sense. I am
> pretty sure there are many other cases there it make sense to control
> several machines from one display, robots?
>
> ------------------------------------------------------------
> ------------------
> 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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[Nicklas Karlsson]

I also have a few robots, ordinary 6 axes. It must make sense to run the
robots without an ordinary GUI, connect remotely with a GUI then
programming.


2017-06-13 9:09 GMT+02:00 theman whosoldtheworld <***@gmail.com>:

> @Niklas robots is the first candidate in my case .... Also because with
> linuxcnc more than 9 axes you can not drive ...
>
> @Chris ... real Good Job.
>
> bkt
>
> 2017-06-12 20:09 GMT+02:00 Nicklas Karlsson <***@gmail.com>
> :
>
> > On Mon, 12 Jun 2017 18:22:07 +0200
> > theman whosoldtheworld <***@gmail.com> wrote:
> >
> > > I have already seen the repository, it can be a way to get to know
> > better ....
> > > but pyqt is not qt c++ ... it does not change much to use py or pyqt
> > > ... said this is a great job.
> > >
> > > Any how my intention is not to make a classic gui for Lcnc local
> machine
> > ...
> > > I find thay in local pc Lcnc is perfect as is it.
> > >
> > > I think is possible it can do something for the group of machines ...
> > > put on each machine a graphical interface is not my purpose.
> >
> > I am with you for group of machines. I have small engraver on or actually
> > below the table and to run in remotely from ordinary PC make sense. I am
> > pretty sure there are many other cases there it make sense to control
> > several machines from one display, robots?
> >
> > ------------------------------------------------------------
> > ------------------
> > 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-***@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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[theman whosoldtheworld]

if you use your robot as ordinary .... probabily is not a good solution ...
but if you use a group of robot as machinery and if the pilot of this group
of robots is a user ... then that makes sense.

Any how i start my homework next mouth ... I'll send you updates on which I
can work/talk.

bkt

2017-06-13 10:39 GMT+02:00 Nicklas Karlsson <***@gmail.com>:

> I also have a few robots, ordinary 6 axes. It must make sense to run the
> robots without an ordinary GUI, connect remotely with a GUI then
> programming.
>
>
> 2017-06-13 9:09 GMT+02:00 theman whosoldtheworld <***@gmail.com>:
>
> > @Niklas robots is the first candidate in my case .... Also because with
> > linuxcnc more than 9 axes you can not drive ...
> >
> > @Chris ... real Good Job.
> >
> > bkt
> >
> > 2017-06-12 20:09 GMT+02:00 Nicklas Karlsson <
> ***@gmail.com>
> > :
> >
> > > On Mon, 12 Jun 2017 18:22:07 +0200
> > > theman whosoldtheworld <***@gmail.com> wrote:
> > >
> > > > I have already seen the repository, it can be a way to get to know
> > > better ....
> > > > but pyqt is not qt c++ ... it does not change much to use py or pyqt
> > > > ... said this is a great job.
> > > >
> > > > Any how my intention is not to make a classic gui for Lcnc local
> > machine
> > > ...
> > > > I find thay in local pc Lcnc is perfect as is it.
> > > >
> > > > I think is possible it can do something for the group of machines ...
> > > > put on each machine a graphical interface is not my purpose.
> > >
> > > I am with you for group of machines. I have small engraver on or
> actually
> > > below the table and to run in remotely from ordinary PC make sense. I
> am
> > > pretty sure there are many other cases there it make sense to control
> > > several machines from one display, robots?
> > >
> > > ------------------------------------------------------------
> > > ------------------
> > > 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-***@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-***@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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[Chris Morley]

Andy is right there is a functional pyqt5 based VCP component on that branch.

While it is missing some of the fancier widgets that gladeVCP has there is a sparce,

but functional demo of controlling linuxcnc.

It is beta for sure and more work is needed but tyer is even some docs...


I should probably put it in master soon...


Chris m


________________________________
From: andy pugh <***@gmail.com>
Sent: June 12, 2017 9:26 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] c++ gui module

On 11 June 2017 at 22:19, theman whosoldtheworld <***@gmail.com>
wrote:

> As you said, me too I try is little bit hard use qt c++ program instead
> Lcnc c/c++ for driving servos machines
>

Not 100% relevant to this discussion, but related: There has been some work
done on integrating QT with LinuxCNC.
See, for example, this feature branch:
https://github.com/LinuxCNC/linuxcnc/tree/qt5vcp_master
[https://avatars2.githubusercontent.com/u/5650508?v=3&s=400]<https://github.com/LinuxCNC/linuxcnc/tree/qt5vcp_master>

LinuxCNC/linuxcnc<https://github.com/LinuxCNC/linuxcnc/tree/qt5vcp_master>
github.com
linuxcnc - LinuxCNC controls CNC machines. It can drive milling machines, lathes, 3d printers, laser cutters, plasma cutters, robot arms, hexapods, and more.


(I know nothing about this branch other than that it exists, though)


--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
------------------------------------------------------------------------------
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-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Emc-users Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/emc-users>
lists.sourceforge.net
This list is for users of the Enhanced Machine Controller (EMC). Topics include how to obtain, install, configure, and use EMC, as well as other general EMC related ...

[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.