Labview UI project for Linuxcnc

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.

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.

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!

Very interesting diagram Aciera, I don't really know what standards are out there, but yes Level 3 & possibly 4 are the ones of interest. I think today these levels are often incorporated into the one ERP system.

Coming from the printing industry there was XML based JDF (Job Definitition Format) and its companion JMF (Job Messaging Format) as defined standards. JDF was an electronic job ticket travelling with the job that could be added to and amended by the workflow (the full process may not be known at the start of the job). JMF was what was used by status updates so machines could provide updates on status back to the ERP/MIS.

So thats kind of what I had in mind. a method like JDF to send a job to a machine and may be start and pause operations with a JMF message.
And a method like JMF so that status updates could be posted back to an API hook published by the ERP/MIS/job scheduler that was listening for status updates.

We use a lot of web based interoperable systems every day in our business and they are tied together by API's with a standard XML or JSON API. These are very trivial to interface with using Python so at a simplistic level, a GUI written in Python on the machine could publish the necessary servers and hook to another IP address to send status updates to.

But in practical terms, for step 1, I'd like to be able to use a nesting program to layout a sheet to be cut on a plasma cutter, generate the Gcode and send it direct to the machine on the production floor. So its sitting there ready to cut.

step 2 might be: hey I've finished this job so schedule it on the next workstation but somewhere there is an operator, so maybe that is done by a human intervention.

or hey we've got some downtime here..

Hi Rod,

I very understand your situation and desires, but linuxcnc is not ready to fulfill your wishes.
The most important value for monitoring is time.
But linuxcnc does not provide any timers.
So what else makes sense to monitor remotely? I don't know.

If linuxcnc would provide toolbased timers, you could monitor a lot (in sense of ERP systems), but without timers?

The only remote thing, that makes sense to me with linuxcnc is a webcam. But a webcam does not need any changes to linuxcnc.
Your step 1 is already possible. As all requirements are outside of linuxcnc.

Step 2 - I don't see any sense in remote capabilities, as human intervention needs local machine controls. From formerly automation projects I know about machines, that had a push button for material request and a push button to signal ready materials to take off.
Such an interface can be realized with or without linuxcnc.