Peter, I think there are good reasons for both approaches, which mainly come down to whether to drive the user interface from the server side or run on the client side. The approach I have taken is to limit as much as possible the server side to running the real time control, making the load on the server more deterministic and less resource hungry. This can become even more important if lcnc can be successfully ported to less powerful ARM type processors. They tend to be more limited not only in CPU speed but memory availability as well.
Thus I would really like to get the core lcnc functions (HAL, motion control, interpreter, etc.) running on a headless Linux server install and only connect GUIs remotely (my applications only, not a paradigm shift of all of lcnc of course). Which of course does not preclude your approach, it only adds to the resource requirements. I also utilize the user interface as the liaison to the client side operating system, which up to this point has been exclusively Windows. The operator only sees the Windows side, an application which looks and feels like any other Windows application, thus the operator does not really care what is running on the control side. Doing this more generically does of course present some problems, but with the recent ubiquitous availability of Linux like devices (Android, iOS, etc.) that would not seem to be a problem going forward. There may be some ways around this when pushed from the server side, but I like the user interface running as an app rather than through a browser. It frees up a little more real estate and it basically locks the operator into the app which occupies the entire screen. Your approach has many advantages as well, foremost is not needing to generate separate packages for each platform. Regarding the back plot, my problem is not rendering the back plot itself, I already have code for that. The problems I have run into are glade specific, things are not rendering at run time the way they are drawn in the glade environment. Components are ending up attached to parents higher in the hierarchy than they are drawn. I have not figured out whether this is a glade problem or something I am doing wrong. Of course I am presuming the latter. So I am really just simplifying the layout until I can figure out what I am doing wrong in more complex layouts. There are several levels of security. Securing the communications would seem to be a simple matter of using certificates and running over https. Securing the operator from what they should and should not be allowed is a different matter and the responsibility of the application. Linuxcncrsh only provides a limited form of the latter. It can limit the actions the operator can take and arbitrates so that only one user interface is in control at any one time. Securing the communications would be a matter of tunneling the desired port(s) over ssh. Otherwise I am in complete agreement on your vision and have often made the analogy between lcnc and the operation of a network router. Regards, Eric Linuxcncrsh interface looks interesting, and it may have some different trade-offs. Let me try to convince you a web server is a better way to go ;-) If you don't agree, that's of course fine too... I'm also going to take a closer look at Linuxcncrsh to see if maybe I went down the wrong path. Here is my thinking for why I used HTML: My intent was to use the most common-denominator interface I could possibly think of, which is what led me to HTML. Just about any platform and programming language has support for connecting to a web page, and you can use a web browser as a test client. I was concerned about speed, but I am able to get updates every tenth of a second on the DRO, so that seems reasonable to me, and no network traffic on items that aren't changing (using a long-polling approach). Right now, the client I'm using is just a web browser on any networked computer. The nice thing about Python is there is a Python API already in linuxcnc, and also a back-plot module from axis, that gremlin uses under the hood. I have been able to have the web server load a g-code file, process it through the backplot code, and write all the results out in a X3D format (XML based 3d format) that FireFox and some other browsers can render inline. Not sure if this will be the best (most efficient) method in the long run, but it shows that it can be done. I'm still new to the web-server-programming stuff. I'm a bit unsure how to properly add security to this paradigm. Linuxcncrsh has a password option. I'm not yet sure how to add this to the Tornado web server, but I'm hopeful there is some simple way to do this. Ultimately, I think it would be wonderful if there was a web based status page for linuxcnc, and also a web based configuration utility that let you set some or all common INI file settings, and then force a linuxcnc restart. Imagine a linuxcnc based controller that you set up as easily as a modern network router (many of which are running linux as well). I think that would go a long way to improving the user experience. I'm working on it... ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
