Receive Serial Port Data

[AlanB]

Hi, I am new to Girder :o and am trying to do send a serial string to my projector and then receive a serial response. My projector is an HT1100 and I can successfully send serial data to the projector but now I need help in how to receive the status data back so I can write a lua script to parse and process the response.

I have the generic serial, winluaex, and luaevents plugins installed/enabled. I am hoping someone can help me:

1) Provide an overview of what I need to do and the development process;
2) Send or point me to an example I can use as a starting point. I believe I need an eventhandler but have not found an example yet.....

Thank you for your consideration
Alan

[Mark F]

I would suggest one more plugin. Get the Logger and enable it. This will give you information about what is happening in the Girder event stream.

You are right, you will probably need an event handler.

In Girder, choose File/Settings... When the dialog opens, choose the plugins tab and find the Serial plugin in the list. Hightlight the serial plugin and press the settings button. When the dialog appears, find and highlight your HT1100 (nice projector, by the way :) ) device in the list and press the choose button. This should bring up ht eDevice Settings dialog for your device.

In the bottom right corner of this dialog is the message definition buttons. You probably already set up the transmit information to be able to send data to the projector. We will change the receive information to allow you to get data from the projector. Press the receive button and a new dialog should come up. This is the "receive message definition dialog".

On the left side of this dialog is the character event information. This is where you set up the parameters to allow you to get full strings or messages from the projector. For example, if each message ends with the same character, you would set up a variable length message with a terminator character.

Once you have the Logger showing complete messages coming from the projector, we will add an event handler (enable the script option on the receive message definition dialog from above) written in LUA and parse the data into meaningful information.

I realize this is very high level but I don't know what you know or need help with so please ask when you get stuck and we can drill down in that particular area. :)

[AlanB]

Thank you for your reply; it's right on as to my level of expertise.

I have installed the logger and have configured it for receiving serial data. It is showing up in the logger. :D

[Mark F]

So now the fun begins. ;)

The Serial plugin distribution includes a few example device support files. Most of them have receive message event scripts. The "easiest" one is the RemotePoint Plus.

In short, the event script is invoked every time the Serial plugin would normally send an event to Girder. A LUA variable, SerialValue, contains the event string data (ie. the serial data you care about). The event script can use strsub() and all the other LUA string manipulation functions (http://www.lua.org/manual/4.0/manual.html#6.2) to parse it into useful information. In the end, most of the device support files I've written use TriggerEvent() to queue an event in the Girder event stream.

The most simple serial event script would look something like this:


-- cause a Girder event
TriggerEvent ( SerialValue, 18 )

[AlanB]

I imported remotepoint plus and have reviewed it. My immediate question is at a higher level I think. I have written a command to get the lamp life so what I did next was to go into the settings for the HT1100 and on the Receive window I enabled scripting and then using the script editor wrote:
print("ht1100 serial data "..SerialValue)
I then saved the script, what next? I ran the command and the logger reported that SerialValue is nul. I then went back into the script editor and the script was gone......hmmmm. The script is still in my folder but girder is not accociating ???

[Mark F]

Unfortunately, the SerialValue variable is only valid during a serial event. IE. it only has a value when the serial plugin is running the script because data was received from your projector.

As for the script being gone, be sur eto press apply or OK at the bottom of the script editor screen before exiting the script editor. Otherwise the data is discarded.

You also need to press OK on all the dialogs until you get to the Serial Settings dialog for this device. Then press Apply and ALL the changes for the device will be applied. (you could press OK instead but then the dialog will close)

[AlanB]

Thanks for the tips on clicking OK/APPLY that took care of the script issue and I could see my message in the logger along with the data. :D I then added a command (OSDTesting) to use the OSD Popup plugin and that worked great. I then wanted to try the triggerevent from the serial receive script so I added:
TriggerEvent("OSDTesting", 18)
I fixed something good :roll: because while the logger appreas in the Windows task bar I am unable to view it. I deleted the triggerevent from the script along with the command so I should be back to what worked at the beginning, still can't view the logger....

[Mark F]

That is weird. :o

Maybe the logger is just off the screen? I don't know.

What we will try is getting rid of the Logger window information in the registry. Stop Girder. Press the Start button, run... In the new dialog, type in regedit and press OK. When the registry editor opens, expand the HKEY_LOCAL_MACHINE node. Expand the Software node. Expand the Girder3 node. Expand the SoftPlugins node. Expand the Logging node. Highlight the MainWindow node and press the delete key. Answer the "yes, I really mean it!" question and close the registry editor.

Start Girder. Is the logger window back? (in the middle of the screen)

EDIT: By the way, nothing you did in the Serial plugin should have caused this.

[AlanB]

OK, my bad :oops: , I increased the screen resoultion assuming I may have accidently moved it off screen, it's baaaaaack.

Moving forward, I added the TriggerEvent("OSDTesting", 18) to the script and the logger records an Event: Dev18 OSDTesting, this is good. :)

Several questions:
1) Since the OSDTesting command is not displaying from the event I must need to? It works using F5 for testing.
2) I used 18 as the event device, how do I know it's 18 or where do I find more info on TriggerEvent?
3) TriggerEvent allows payloads, how would my OSDTesting command access the payload? Scripting? Using payloads would allow me to have one OSD command that can display various messages based on a unique payload, am I off base here? If not I am assuming there might be a way from scripting to invoke and OSD message.

[Mark F]

OK, my bad :oops: , I increased the screen resoultion assuming I may have accidently moved it off screen, it's baaaaaack.
Stuff happens. ;)


Moving forward, I added the TriggerEvent("OSDTesting", 18 ) to the script and the logger records an Event: Dev18 OSDTesting, this is good. :)

Yup. This is a VeryGoodThing(tm).


Several questions:
1) Since the OSDTesting command is not displaying from the event I must need to? It works using F5 for testing.

Even though you named the command and event string the same, this doesn't establish a connection between the two.

To extablish the connection, you have to learn the event to the command. Highlight the OSDTesting command in the command tree. On the right side of the Girder window there is a dropdown list. It is right next to the Learn Event button. Drop that list down and choose "Girder Event". Press the Learn Event button and a dialog will pop up. Type the value of the event string that you used in the TriggerEvent() command (OSDTesting) and press select. Now when this event is generated, the command will execute.


2) I used 18 as the event device, how do I know it's 18 or where do I find more info on TriggerEvent?

18 signifies that this event was generated by the "Girder plugin". Each plugin has a different ID number. By using 18, you get to use the interface described above to learn an event.

The other plugin IDs are on one of the developer's pages elsewhere on this site. You can also get this information by looking at the DEV: part of the generated events in the logger window.


3) TriggerEvent allows payloads, how would my OSDTesting command access the payload? Scripting? Using payloads would allow me to have one OSD command that can display various messages based on a unique payload, am I off base here? If not I am assuming there might be a way from scripting to invoke and OSD message.
Since you are using the OSD Popup, I know the answer. In your command, in the area where you type in the text you wish to display, you can enclose variables in brackets. In the case of events, the payload strings are placed into the variables pld1 - pld10 before the command is sent through the Girder tree. Place [pld1] in the OSD PopUp command and the first payload string will be displayed.

Since payload data variables are just normal LUA variables, they can be used in scripting commands or anywhere else a LUA variable is valid.

NOTE: The payload data is transient in nature. After the event processing completes, the pldX variables may contain different data or no data at all. If you need to save a value that travels as payload data on an event, place it into a different LUA variable for safe keeping.

For example, there are many people who use little VFD displays on the front of their PCs. The have scrolling information about the state of the machine on this display. Much of that data is gathered from the payload data of events passing through the system. The data is captured during the event processing and saved into other LUA variables for later display.

[AlanB]

OK it's getting sacry becuase it's starting to make sense as well as work. This should do me for now.....

Thanks so much, you've been a great help.

Alan

[Mark F]

Glad to help. Don't hesitate to ask more questions. :)

[Promixis]

Alan, when you have it done, would you please upload the ini and gml files under the developer/upload area?

[AlanB]

Will do.