Labview UI project for Linuxcnc

Reinhard wrote:

But what is the benefit of such a work? Do you really want to drive your plasma cutter resting in your living room and playing with your tablet?

Why do factories centrally manage their welders via a TCP network?

The world today is all about interoperability of disparate systems. My cloud based accounting system has a manufacturing module.
It supports connected micrometers and other measurement devices to ensure quality on the factory floor. Surely its not too big of an ask to allow the ERP system to manage the jobs that are sent to the individual machines and then in turn monitor progress for productivity? After all the ERP system stores the work instructions for a particular product..

You need to look at the big picture. The machine tool needs to be part of a larger system.

Hi Rod,

Why do factories centrally manage their welders via a TCP network?

Well, its a difference, whether you have a huge shop with automatic transportations and much robotics, or if you have a hobby or midrange professional shop.
I work at a midsize company with erp-system, lot of mills, lathe and robotics, but no machine is controlled remotely! And there are no plans to change it.
.

Surely its not too big of an ask to allow the ERP system to manage the jobs that are sent to the individual machines and then in turn monitor progress for productivity? After all the ERP system stores the work instructions for a particular product..

Well, look a bit closer to that picture. ERP manages jobs, which might reach from 3D-drawings to GCode-files, but I don't know of ERP systems, that controls mills or lathe.
As said, I work at a company that uses ERP system - and that means, Drawings and GCode are stored in a central repository and accessible at all places.
When starting a new job on a machine, the gcode gets pushed to that system, but everything else is handled by the machine controller and the man in front of the machine.
You have to manually change the tools in the atm and finally try the job with the first part in single step mode.
Then measuring happens and when everything is fine, the real job starts.
We do have multiaxis mills, that are capable of measuring the whole part. But that measuring is slow and cumbersome, so that it is rarely used.
.

You need to look at the big picture. The machine tool needs to be part of a larger system.

I'm aware of the big picture. But some people have simply wrong ideas and requirements.

If you want to include a linuxcnc system in an erp-system, most jobs are remote actions with the PC, where linuxcnc runs (like file-transfer) and may include status feedback (but without realtime requirements).
ERP system don't care for current position of tooltip, but for estimated runtime, passed runtime, workload of tools, lifetime of tools, wear parameters ...
All these can be accessed already from linuxcnc (well, beside of runtime of job, used time of tools), so in my beliefs remote access is not a feature, that linuxcnc must provide. It can be achieved with small addons.
linuxcnc already contains lot of tasks, that are not typically tasks of machine controllers.

I vote for to focus on real machine controller tasks and not ask for weired and dubious extensions.

I'm pleased that I have generated interest in this area and that sooner or later the interface that I desire will end up being present in LinuxCNC and it will be very beneficial.

I shall certainly continue to work on accomplishing this on my end for my own use as a minimum. My goal right now is to use shared memory and pointers to accomplish. Not sure yet if only real time memory needs to be considered or if user space memory also needs to get involved due some variables hiding within it.

I do not expect this to be easy to accomplish but as knowledge of the NIST and other code that is presently there increases it will get easier.

I was wondering when you say: "I vote for to focus on real machine controller tasks and not ask for weired and dubious extensions."

Would you consider UI interfaces for QtPyVCP or Qtvcp weired and dubious extensions. These are add on things that add a lot of code just to make a UI look a bit more appealing but not really needed to control a machine. When looking at the network ability it is actually built in and not a add on so there is no way that it can ever be weired and dubious.

There is no way of telling how a machine or a UI is actually connected to a machines controller when standing in front of the machine. If it is fairly modern it likely uses multiple network connections internally for system control.

So there is really nothing weired and dubious about utilizing the network ability that is and was built into LinuxCNC from its beginnings at NIST. Making a improvement to the network ability of LinuxCNC is a improvement to the core of LinuxCNC itself.

Lets all be positive and promote desires for updates such as this since in the end LinuxCNC will end up being better than ever.

@auto-mation-assist
you're comparing apples with pears!

Let's be precise:
.

So there is really nothing weired and dubious about utilizing the network ability that is and was built into LinuxCNC from its beginnings at NIST.

Network ability is part of nml-api as a choice, not as a must use.
Linuxcnc uses shared memory, which is one option of nml. You can use nml in network environments, but then you need to compile code different (I hope so).
When you look at all the nml-classes, they contain lots of update functions. Those functions are relevant for network usage only, so for shared memory usage, code could be compiled that way, that the linker strips out all update functions.
For me, all your whining speech about misbehaving network api of linuxcnc shows a misunderstanding of network and linuxcnc (or machine controller in general).

So what I consider weired and dubious, is the request of using network in realtime part of controlling. Its simply stupid, as network requires number conversion, which could waste lot of time. Realtime parts should be coded as fast as possible.

Network is - of cause - appropriate for status delivering to whatever clients may be interested in machine status. Status delivery is outside of realtime requirements.
Any interface may be established, as long as it does not affect realtime functionality of linuxcnc.
But that will not happen, until a developer personally wants that functionality and spends his time on coding that stuff.
I for sure don't even want network in machine-controllers.
The PC that runs linuxcnc has network - that's enuf for me

I know, that there are realtime drivers, that use network as connection - but I'm no friend of that parts. They work if you slow down threads, so that network is fast enuf to deliver required data, but internal cards can provide much more performance.
I'm quite sure, if you want multiaxis closed loop control with precision and speed, there's no alternative to internal mesa cards.

Reinhard wrote:

@auto-mation-assist
You can use nml in network environments, but then you need to compile code different (I hope so).

I don't think thats the case. you just need to change some IP addresses in the config files..
See
github.com/LinuxCNC/linuxcnc/blob/master...gs/common/client.nml
github.com/LinuxCNC/linuxcnc/blob/master...gs/common/server.nml

Its not helpful to have a closed mind when remote access is discussed.
I'm sorry Reinhard but I think you've been talking nonsense in this thread.

Quite clearly there is going to be a machine controller for the machine dealing with the real time control but the GUI can live anywhere on the network.

But currently that implies another copy of Linuxcnc running elsewhere on the network. Interoperability to me implies its OS agnostic. I don't really care what OS system I use. eg. I might have nesting software or a post processor running on a non-Linux OS. It may even be web based. Why isn't there an API that would allow me to submit that job direct to a machine? Why shouldn't I be able to see status updates as it runs? Why can't I monitor a job running for a few hours from the comfort of my office while I'm doing other things? Why can't there be a 65" monitor int her factory showing the current state of production?

Quite clearly there is going to be a machine controller for the machine dealing with the real time control but the GUI can live anywhere on the network.

No, not really.

If you want, you may have a secondary GUI anywhere in your network. But the primary GUI has to be at the machine.
What if you put a new sheet of metal on your plasma and need to measure the workpiece origin and orientation. You can't manage that from your living room - you have to be near to the machine.
Its the same task for mills, lathes and plasmas - to setup the machine for a new job, you need to be at the machine and have your (realtime) controls at hand.
That's a requirement, not an option.
Having a GUI on your tablet in your living room is an option, not a requirement.
That's all, what I was talking about.

The rest of your questions - I don't see a conflict to my earlier statements. All your wishes are technically possible. It only needs a developer, that wants to implement it.

Reinhard wrote:

[
If you want, you may have a secondary GUI anywhere in your network.

Thats the thing, its far more than a second GUI, its being able to allow multiple disparate systems to interoperate.

Aciera wrote:

Why shouldn't I be able to see status updates as it runs? Why can't I monitor a job running for a few hours from the comfort of my office while I'm doing other things? Why can't there be a 65" monitor int her factory showing the current state of production?

So are you guys in agreement that real time operation is not required for monitoring purposes?
As I see it, user interaction is per se not real time so is the GUI. Or am I missing something here?

Are you talking about something like Octoprint for LinuxCNC? That is something I could see to be useful.

I guess you guys may already be familiar with ISA-95 - this version of the pyramid has rough timing requirements.


(Not my picture, nicked from here ).

I'd be lying if I said I'm following the whole conversation, but it's interesting because there are lots of people selling I4.0 under the guise of connectivity, lots of managers who believe it's important (but don't necessarily know why they want it), some definite benefits to the connectivity...but really a lot of the froth is really I3.0! Not trying to paint Rod as a straw man here by the way...I just get a bit less interested at a factory level!