How to define an communication server action? (Client)

[mhund]

Hi,

I am new to girder 4 beta so maybe my questions will be simple.

I understand, that former Internet Event Server is Communication Server now. But what is the action for Communication Client (former internet event client)?

[Rob H]

Not sure I understand the question - do you mean the device id?

[mhund]

No, I mean: How can I trigger Communication Server events? In G3 I had the Internet Event Client. But I can not notice a Communication Client/action available at G4 ...

[Rob H]

If you open the log display then you can drag events from there to your commands. The device id is 232 I believe.

[mhund]

Sorry - must be my bad english ...

I am looking for the ACTION; not the event. How can I set up an ACTION, which is related to another communication server?

Shure, one way would be having a script with a TriggerEvent. But I am looking for the G4-way of "Internet EVent Client"

[Mastiff]

There are none. There are only scripts. I have made it a bit easier for myself by defining functions in a startup script:

Kom={}
function Kom.C1(msg) --server
if not Kom.con1 then
Kom.con1,err = comserv.NewConnection( '192.168.0.1', 20005, 'girder');
win.Sleep (100)
end
local seq, err = Kom.con1:SendEvent(msg,200,1)
if err then
Kom.con1:Close()
Kom.con1,err = comserv.NewConnection( '192.168.0.1', 20005, 'girder');
win.Sleep (100)
local seq, err = Kom.con1:SendEvent(msg,200,1)
end
end

function Kom.C2(msg) --Home office
if not Kom.con2 then
Kom.con2,err = comserv.NewConnection( '192.168.0.2', 20005, 'girder');
win.Sleep (100)
end
local seq, err = Kom.con2:SendEvent(msg,200,1)
if err then
Kom.con2:Close()
Kom.con2,err = comserv.NewConnection( '192.168.0.2', 20005, 'girder');
win.Sleep (100)
local seq, err = Kom.con2:SendEvent(msg,200,1)
end
end

Where after the IP address there's the port (20005) and the password (girder). Then the commands in each script are limited to calling the function and adding the event string. And the variables are in a neat table in the variable inspector. This script also checks that the connection is open, and it opens one if not, but if one is open, it will use that. Note the win.Sleep commands - without them the script will fail on fast communication back and forth. In reality you won't notice a slowdown of a few 100 ms. Here is the command that is needed in the individual scripts, or "Internet event clients":


Kom.C1("comtesttoserver")

If you want to send payloads as well, there are two ways. Since most of my commands don't send payloads I prefer to keep this function the way it is and then use a single script with:

if not com then
com,err = comserv.NewConnection( '192.168.0.1', 20005, 'girder');
win.Sleep (100)
end
local seq, err = com:SendEvent("event string",200,1,'payload','payload','payload','payload')
if err then
com:Close()
com,err = comserv.NewConnection( '192.168.0.1', 20005, 'girder');
win.Sleep (100)
local seq, err = com:SendEvent("event string",200,1,'payload','payload','payload','payload')
end


In the last version the first payload will be the socket ID, so Payload 1 will be Payload 2. In the help file it says that payload 1 is the IP address, but I don't get that... Maybe somebody would like to explain that one? In the OSD I have used:

[EventString]
[pld1]
[pld2]
[pld3]
[pld4]
[pld5]


That shows the event string correctly, then the socket ID as Payload 1, and then the numbered payloads that the client sendt as 1-4. Where the IP comes in I have no idea.

Of course all the big boys here would make it into a very elegant and advanced package, but probably more cumbersome to use, their chosen command would probably be:

comserver(192.168.0.1,20005,'password','eventstrin g','payloads')

I prefer the simple route, even if the script isn't as tidy as what they would make.

Edit: I know one of the big boys will be here soon and point out my shortcomings, but hey, give me a good grade for effort, at least! :wink:

[mhund]

Hi Mastiff,

thank you very much for your post. You are the one who understands what I mean. But your answer does not satisfy me really. At girder 3 it was easy to exchange events between two girder instances. Is that true, that in girder 4 intercommunication is only possible by script code?

I hope the communication client part of the plugin is still in development and will be available soon. I liked G4 so far but as long this is not available, girder 4 will only be a playground for me but not a serious substitute für G3. I wonder, wy no one else is complaining about that in this forum...

[Mastiff]

Probably because most of us, like me, have been aching for a way to do this in Lua. :wink: I'm 3/4 done migrating my systems (took less time than I thought), at least i theory - I have the GMLs ready, but won't test them until my wife and kids leave for her parents' for two weeks. What's mostly missing is the generic serial support... And Lua's taking more and more of this. In my opinion, using the function method, it's easier to add an Internet Event than it was in Girder 3.

Yes, scripting is both daunting and a major pain in the you-know-what in the beginning, but after a while it gets fun. Then the pain transfers to other forum members, like Mike, Rob, Marcel and so on, who get bombarded with endles questions... 8)

[Rob H]

Well, I wouldn't complain because I'm much happier with scripts :)

[Promixis]

Probably because most of us, like me, have been aching for a way to do this in Lua. :wink: I'm 3/4 done migrating my systems (took less time than I thought), at least i theory - I have the GMLs ready, but won't test them until my wife and kids leave for her parents' for two weeks. What's mostly missing is the generic serial support... And Lua's taking more and more of this. In my opinion, using the function method, it's easier to add an Internet Event than it was in Girder 3.

Yes, scripting is both daunting and a major pain in the you-know-what in the beginning, but after a while it gets fun. Then the pain transfers to other forum members, like Mike, Rob, Marcel and so on, who get bombarded with endles questions... 8)

Tor, it still cracks me up that you have turned into a script kiddie.

[mhund]

Mike, can you confirm that sending communication events will stay possible only by scripting?

[Mastiff]

Mike, you've got a lot of the blame for that on your shoulders! :wink:

[Promixis]

Mike, can you confirm that sending communication events will stay possible only by scripting?

In the short term yes. We are looking adding as many actions as possible to the action tree and this will be done over time. Our major goals are to finish and test functionality and then focus on usability issues.

[Mastiff]

Since it's a lot easier to type it in a script, using a function, wouldn't this be the smart way to do it? Something like what I'm doing, where you only have to write the name of the function and the last part of the IP of the computer you want to send to (could prehaps be expanded to computer name) and the event string. Come to think of it, perhaps I should change this to using the last part of the IP as an argument, so I won't have to have one function for each computer?