Thnks for your input EBo!
Part of the project is promised to take shape this week.
That means it's in the nuts&bolt-phase, at least partially.
The GUI is prioritized and Glade is suggested to be used.
Pythons TCP-inteface is also in the pipe.
Tried this yesterday:
******************************************
# Echo server program
import socket
HOST = '' # Symbolic name meaning all available interfaces
PORT = 50007 # Arbitrary non-privileged port
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((HOST, PORT))
s.listen(1)
conn, addr = s.accept()
print 'Connected by', addr
while 1:
data = conn.recv(1024)
if not data: break
conn.sendall(data)
conn.close()
*******************************************************************
with it's clientpart.
I guess this code could run with Glade?
And then we have the issue of interfacing LinuxCncRsh(LCRsh) to Glade.
It's functions:
- Create socket conections to all targets
- Load all target files. (max 10)
- Start all targets
- Monitor all systems over LCRsh
(Synchronism will be solved separately in this stage.)
This could I guess, all be done in Glade/Python creating the following GUI
items:
- TCP address list
- G-code source file list
- per target main state indicators a la Axis:
> From: EBo <[email protected]>
> Subject: Re: [Emc-developers] LinuxCNC-cluster run by Modbus etc...
> To: <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> I guess that the only thing I can add at this point is that you can
> have course- or fine-grain parallelism. I can easily see how to do #3
> below using a course-grained approach by writing separate programs in
> each one of the work envelope regions, and then having a master command
> the machines in basically a task based approach (and wait until each of
> the tasks are done before moving forward). The nice thing about this is
> that the workload can be adjusted on the fly to accommodate networks of
> machines that do the same operation. All that being said, I did not
> think that that is what you had in mind...
>
> On Sat, 8 Sep 2012 11:39:49 +0200, Roger Holmquist wrote:
>> Hello again!
>>
>> Well, I have to comment my last slighly cryptic post and focus on the
>> subject.
>>
>> The subject is a cluster of syncchronized LinuxCnc-driven machines.
>>
>> That means U have to add ccertain functionality beyond LinuxCNC.
>>
>> 1) Remote controlling every machine
>> 2) Remotely feed it with Gcode
>> 3) Take care of synchronism, fault states and collision risks.
>> 4) ( A GUI )
>>
>> 1) Seem to be solved by using LinuxCncRsh who can
>> - Load a gcode-file
>> - execute it
>> - monitor it
>> - recieve certain fault states
>> - terminante it
>>
>> 2) could be done over ftp -or- by dripfeeding over linuxcncrsh
>>
>> 3) is the hard part, possible support may come from subsystems like
>> - MODBUS SW
>> - REDIS
>> - Ladder logic
>> - TCP socket managing SW, may be included in some of the above
>> packages
>> - Something else?
>>
>> The preferred configuration is supposed to be Master-Slave with one
>> of the machines configured as master.
>>
>> The GUI should be an non-systemdependent addition, U should be able
>> to run the system from terminal just like LinuxCncRsh
>>
>> Could it be simplified?
>>
>>
>> / Roger
>>
>> 7 sep 2012 kl. 19:42 skrev
>> [email protected]:
>>
>>> Yes the emcrsh is renamed and linuxCNC who is installed, seem to
>>> leave my request to open that nonexisting task in silence or is it
>>> any logfile somewhere?
>>>
>>> linuxcncrsh runs just fine, haven't checked all functionality yet
>>> but it looks good.
>>>
>>> Now I need an engine with tcp-connectivity for synchronism and
>>> error-handling...
>>> And a GUI...
>>> I think I mentioned that earlier, MODBUS was named, seem to be
>>> integrated somewhere already after some brief encounter in the
>>> linuxCNC jungle....
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
