View Full Version : Generic Serial and LUA

July 3rd, 2006, 11:42 AM
Hi All,

It's been a while since I played with Girder, but I am getting frustrated with my current solution (to remain nameless) and I'd like to re-visit serial control of deivces via Girder.

I am very well versed in serial protocols and I can achive transmit (1-way control of just about anything I want using the Generic Serial plugin).

I change out my gear more frequently than most and I'd like to be able to process incoming feedback using the LUA scripting in the Generic Serial plugin. The problem is I am not very familiar at all with LUA and that is where I am looking for some help. I have downloaded what I think are the appropraite LUA docs and frankly it is a bit intimidating.

What I am hoping to do is have a couple of basic scripts that can pattern match incomig ASCII or Hex strings and set Girder variables accordingly. Any examples of these kinds of scripts with lots of comments on what each piece is doing would be incredibly helpful.

I would then tweak the scripts to match the particular device I am trying to control and plop that code into the receive script section of the Generic Serial plugin.

Thanks in advance.

July 3rd, 2006, 12:29 PM
John, Girder 3 is no longer for sale. So building a new solution on this is not a smart thing to do as the Girder 4 serial plugin is very different. We'll be happy to help out with that.

July 9th, 2006, 01:15 PM
What is the learning curve like migrating gmls etc to v4?

Rob H
July 9th, 2006, 01:18 PM
It depends on what your gmls do really, and what plugins you use

July 9th, 2006, 04:24 PM
What is the learning curve like migrating gmls etc to v4?

John, we will do our best to make it as painless as possible.

July 14th, 2006, 10:23 AM

Still stewing over I want to make the leap. I'd realy like to see this work in v3 so I don't have to change everything.

July 25th, 2006, 02:25 AM
I have played with LUA a bit and I am starting to get the hang of it, but I have one small issue that has cropped up.

I am using a device (ADA Suite16) that I can send a status request to, and it will respond with 12 status messages, 10 ascii characters long, for each of 16 zones.

As a test, I just redirect each command down to the main tree and then do a http send to a 3rd party device.

The receive script looks like this:

if (SerialValue ~= nil) then
TriggerEvent ("Suite16Stat",18,(SerialValue))

As I said this passes data down stream to the tree to be sent out via a http command. I would do it all in one script, but if I place this code inthe receive script, it will not run.

The Suite16Stat event triggers this script.

local adacommand = (pld1)
local url =("|adatestvar~"..(adacommand))
local httpreq = luacom.CreateObject("WinHttp.WinHttpRequest.5.1")
httpreq:Open("GET", url, 0)
collectgarbage ()

This all seems to work, I get all 192 messages sent over to the http device, but after processing all those messages, Girder gets really slow and eventually hangs with the cpu spinning at 50% just for Girder (3.8GHz PIV CPU). The only way out is to kill the Girder process with Task Manager and re-start.

If I do not run the second half of the script, Girder seems to stay happy, but of course I can not send data to my third party device.

So I have two questions.

1. Why is Girder getting upset?
2. Is there a way to incorporate the second half of the script into the first? I tried to do this and it did not seem to run.

July 25th, 2006, 02:46 AM
I made a few mods to the second script for testing and this is what happened.

local adacommand = (pld1)
print (adacommand)

This works as advertised, I get all 192 messages printed out in the LUA console and Girder stays happy.

Then I did this:

local adacommand = (pld1)
local url =("|adatestvar~"..(adacommand))
print (url)

This had the same bad effect on Girder

So it appears I have narrowed the issue down to this one line of code (the setting of the (url) variable).

Any ideas why this breaks Girder?

July 26th, 2006, 05:57 PM
That is very weird. You sure that is all that is going on? Did you test the first code sample a couple of times?

Please post the actual data.

July 26th, 2006, 06:18 PM
That is very weird. You sure that is all that is going on? Did you test the first code sample a couple of times?

Please post the actual data.

Yes I am pretty sure that is it. The script I wrote is actually much more involved, but I commented it all out trying to track this down. As a further test I can save it off to a gsf and just delete all the comments. Do you think that is worth trying?

I am thinking this should be pretty easy to replicate, just do table with 192 entries in it, I can even send you a file with all the actual text. Have that PC do serial sends to into another PC (or port) that has the same scripts as I do. It'd be interesting if it would do the same thing.

I have tried this on 2 separate machines and they both do this consistently.

What do you think?

Edit: With the F10 thing in mind, I tried to re-run some of the earlier tests. I found that even with the simplified script. If I run it more than once and then hit F10 it will also cuse the high CPU / hang up issue.

So for now it seems that F10 is central to this issue. It is unfortunate since I have used that a lot when writing this script and I see it as a very handy tool to see what LUA is up to.

Can anyone think of a workaround?

July 27th, 2006, 01:22 PM
sorry not really.

July 31st, 2006, 04:58 AM
OK, It seems to be working smartly if I don't use the F10 key.

Thanks anyway.