Properties[] returning nil

[jcdammeyer]

Hi,

I'm really new at this so I may have just mucked something up. Last night (more like 1:30AM) I had the touch screen sending text messages out the serial port to my custom LED light. This morning I went back in to start enhancing things and suddenly I'm getting this sort of error message.

p1

p2 (nil) failed to find -->Send Light 1 ON

[string "Lua Code"]:204: attempt to concatenate local 'message' (a nil value)

I'm using the generic RS232 driver from Alan Chow. I've modified the lua code to add debug statements so I can figure out why it's suddenly broken. The Properties page of the Generic Lighting Driver shows Hex/Ascii as Ascii and the code makes it through that test.

Then, it dies here:

if (Properties["Hex/Ascii"] == "Hex") then

packetToSend=tohex(Properties["Send Light " .. i - 5000 .. " ON"])

else

print("p1")

packetToSend=Properties["Send Light " .. i - 5000 .. " ON"]

if (packetToSend == nil) then

print("p2 (nil) failed to find -->" .. "Send Light " .. i - 5000 .. " ON")

else

packetToSend=string.gsub(packetToSend, "<cr>", "\r\n")

end

end

In the Lua Command window

if (Properties["Send Light 1 ON"] == nil) then

print("Nil Properties reference")

else

print(Properties["Send Light 1 ON"])

end

outputs "Nil Properties reference"

So although the Properties screen shows the text and has ascii data to be sent the table Properties[] seems to not have these as indices. What am I doing wrong? It used to work.

Thanks

John

[ILoveC4]

John, I can't help you fix this, but I can tell you that it sounds cool.

If you can get it working, I would love a further explanation as to exactly what it will do for you, and would love to possibly try it out in my project.

Good luck getting it working...

[jcdammeyer]

The problem is the Properties table is global to the system and now is suddenly not there anymore. I created my own table and indexed it with the same values as used in the property table and that all works. So somehow, something in the LUA interpreter is no longer interpreting.

More than likely I've accidently done something and there's no error message for it. Nothing in the system log file either

John

[RyanE]

More than likely, you have a syntax error in the <script> section, and when it initially loads the driver, things are not loading properly.

I've *never* seen a DriverWorks driver's Properties table not work properly in any other case.

RyanE

[jcdammeyer]

I took a step backwards and scrubbed the drivers from the system. Then made sure there was only one copy anywhere of my modified driver with the debugging statements. Then renamed all the generic ones that I started with to not end in .c4i. Next I loaded it under CodeWrite and made sure that it had DOS CRLF pairs for all line ends. Turns out the file was mixed between DOS and LINUX line ends. That may have caused some problems.

Finally restarted Composer 1.8.2. Then under "My drivers" I added the driver and placed in the 'living room'. Did the proxy connections to the Outlet Lights and the second serial port and refreshed the Navigator.

My five Lights ICONs are on the remote display. Pressing the button turns on and off the lights. The LUA log display shows:

ReceivedFromProxy [5001] : ON

p1

SendToSerial:W255

packet to send : W255

serial data = W->CAN=0255

ReceivedFromProxy [5002] : OFF

p3

SendToSerial:R0

packet to send : R0

serial data = R->CAN=0000

ReceivedFromProxy [5001] : OFF

p3

SendToSerial:W0

packet to send : W0

serial data = W->CAN=0000

ReceivedFromProxy [5001] : ON

p1

SendToSerial:W255

packet to send : W255

serial data = W->CAN=0255

So I'm now back to square 1 but with working devices. Next is to see whether I can get the serial received data to match. Then add the features for setting the intensities rather than discreet on/off.

But at least it works! The LED lights I'm driving are actually on a Controller Area Network (CAN) bus system and I have a small PIC micro-controller that translates the RS232 commands into CAN messages. The lights are similar to these that I designed last year:

I'll post photos of the fixtures once they are installed. They have white, red, green, blue LEDs in a linear strip about 1.5m long. Each individual LED can be controlled but for now I'm running the fixtures as groups of all one colour. I'll use a DMX-512A to CAN module to run light shows controlling single LEDs with Light-O-Rama software.

John

[jcdammeyer]

Support of LUA is really wanting on this system. Here's an interesting and reproducible problem

I bring in .c4i driver and connect to RS232 port of the HC200. Then connect the proxies to Wireless Outlet Dimmer and move the sliders on the mini touch screen to change my LED intensities.

Right Click my the driver on System Design Page and then left click Edit Driver... and then click OK

NOTE!!!! No changes to the file. Nothing. Just Click OK.

The result is as follows as shown from the following code fragment:

 
       print("Before Properties is accessed where i=" .. i .. " and Level=" .. Level)
       packetToSend=Properties["Send Light " .. i - 5000 .. " ON"] .. Level .. "\r"
       print("After Properties is accessed ")

and here's the output.

ReceivedFromProxy [5003] : SET_LEVEL

Before Properties is accessed where i=5003 and Level=146

[string "Lua Code"]:120: attempt to concatenate field '?' (a nil value) (ReceivedFromProxy)

Notice it crashes before the "After Properties is accessed". This is repeatable.

This is what it looks like when the .c4i file is imported.

ReceivedFromProxy [5003] : SET_LEVEL

SendToSerial:G220

packet to send : G220

Rx serial data = G->CAN=0220

ReceivedFromProxy [5002] : SET_LEVEL

SendToSerial:R54

packet to send : R54

Rx serial data = R->CAN=0054

The solution, tedious as it may be is use an external editor, modify the code. Cut and paste fragments into the LUA command screen and test them. Then delete the existing driver and all the proxy linkages that go with them. Bring in the newly modified c4i file and set up the linkages again. As long as connecting the Control Inputs RS232 port to the HC200 port produces this text:

ReceivedFromProxy [1] : GET_CAPABILITIES

ReceivedFromProxy [1] : SERIAL_BINDING_BOUND

then I know the .c4i file was read in correctly without syntax errors. Linking in the proxies results in

ReceivedFromProxy [5001] : PROXY_NAME

ReceivedFromProxy [5001] : CAPABILITIES_CHANGED

ReceivedFromProxy [5001] : AV_BINDINGS_CHANGED

And then test. A very tedious design cycle all caused because Driver Edit window breaks the code somehow.

Also very confusing are the number of different places that Drivers can be loaded or touched with different results. The Manage Drivers Menu selection is particularly scary because it deletes the file from the folder without even asking if we really want to do that even though one would assume the request is to delete it from the internal database.

Anyway, I have a simple system running the LED displays which will make my customer happy. No confidence that it will run tomorrow but at least it's working.

John

[RyanE]

Yeah, that's why the 'Edit Driver' functionality is slated to be changed considerably in the 2.0 release.

'Edit Driver' and 'Export Driver' are not available for DriverWorks drivers in 2.0 and later.

Most of us developing driver have used an external editor from the beginning, and that route has been tested considerably better than the 'Edit Driver'.

Sorry you've had issues with it.

The recommended way to do it (in the current version) is as you have expressed, with one change. Instead of deleting the driver and adding and re-doing all your bindings, you can pull in an additional copy of the driver, delete it (the one you just added), and restart Director. When it restarts, it will load up your driver with the new version, and your bindings will remain.

RyanE

[jcdammeyer]

There must be one step missing in your instructions or I've misunderstood.

In the items pane under Search I double click on my driver. It then shows up in the System Design pane as CAN2RS232 Driver 2 since I already have a CAN2RS232 Driver.

I see that the properties are correct and that there are of course no connections.

I then delete CAN2RS232 Driver 2.

I quit from Composer 1.8.2 (I think that's what you meant by restarting Director?)

I restart Composer 1.8.2 and open up the LUA panel to watch the diagnostics. The single change I made was to comment out a print statement.

Alas, when I toggle a button on the Mini Touch Screen the print statement is still there.

So what have I missed?

Thanks

John

[RyanE]

No, Director is the software running on your controller.

You can disable it and re-enable it in System Manager.

RyanE

[jcdammeyer]

Correct Nomenclature is????

Menu:

File | Disconnect from Director

File | Connect to Director...

Which means disable and re-enable?

Thanks

John

[RyanE]

This is the kind of stuff you'd learn on the first day of Dealer training, and one reason why typically *dealers* make drivers.

Tools -> System Manager -> Connect to the Controller -> Status -> Enable/Disable.

RyanE

[dgbrown]

^ Ryan,

While your statement is accurate reference "*dealers*", you guys really need to get more "real" programmers into your driverworks program. Dealer fluency in LUA has got to be low at best given the abundance of "new" LUA based drivers.

And the lack of Flash Lite, Actionscript, etc, fluency will magnify this point when the 4Store hits the market.

It would be great to consider an open forum dedicated to building apps and drivers.

I say this ONLY because I care

** Disclaimer: C4 is an independent company, entitled to run unencumbered by outside opinions.

[jcdammeyer]

Discussion on 'dealers' and their capablities is probably best done by starting a new thread since this one is on the missing Properties Global table.

That problem is now solved since I discovered that using the "Edit Driver..." feature of Composer 1.8.2 results in damage to the LUA interpreters data environment. '

A side by side compare of the original dirver and the one 'exported' by Composer shows there is no difference other than the placement of certain sections of theXML blocks. That in itself should not cause the run time environment to be damaged. So we have a bug.

In my world of embedded systems using Microchip, Freescale, TI Code Composer, Delphi, Microsoft C, I rarely ever see this sort of bug. But it can happen.

So for me this particular thread is done since I now know why the Properies[] array is no longer visible in the data environment and that it has nothing to do with my .c4i script.

John

[slater]

This is the kind of stuff you'd learn on the first day of Dealer training, and one reason why typically *dealers* make drivers.

Ryan, John is working on this driver for me...a dealer... He is writing this driver directly for my client who has custom built LED sabers being installed in his home. Your comment almost cost me/C4 a client as he felt your tech support was lacking.

Dealer, homeowner, or hired programmer...we can all use help at times!

[dogdvr]

Slater,

Really??

PM me

Brent

[RyanE]

Ryan, John is working on this driver for me...a dealer... He is writing this driver directly for my client who has custom built LED sabers being installed in his home. Your comment almost cost me/C4 a client as he felt your tech support was lacking.

Slater,

I have no problem if you have someone working on a driver for you. He could've let me know that up front, and asked for help.

I apologize if I put you in a rough spot, but not knowing puts *me* in a rough spot. I participate on these forums on my *own* time.

I'd offer more support knowing he is working for a dealer.

RyanE

[slater]

Its all good Ryan, lack of communication always creates havoc. I didn't mean for you to land in a bad spot. For that I apologize.