Phidget setOutputState not working

[khun]

Hi!

I haven't yet gotten the setOutputState of the PhidgetInterfaceKit to work after upgrading to G5 and Phidget 2.1 COM. All my Phidget code follows, near the end is the PhidgetSetOutput function, which doesn't work. Note that there is no error message, the problem is that the call doesn't trigger any reaction. Or to be precise, sometimes it does, but it doesn't correspond with the parameters sent to it!



-- ensure only run once
if PI then
return
end

require 'DelayedEventClass'

PI = luacom.CreateObject ("Phidget21COM.PhidgetInterfaceKit")
PI:Open(-1)
PIEvents = {}
PDelayedEvents = {}
function PIEvents:OnAttach()
print ("Attached")
print ("Phidget Interface ".. tostring (PI.IsAttached))
print ("Serial ".. PI.SerialNumber)
print ("Version ".. PI.DeviceVersion)
print ("Inputs "..PI.NumInputs)
print ("Outputs "..PI.NumOutputs)
print ("Sensors "..PI.NumSensors)
for k = 1, PI.NumInputs do
PDelayedEvents [k] = DelayedEventClass:New (50,nil,'PhidgetsInput:'..k,18)
end
end
function PIEvents:OnDetach()
print ("Detached")
end
function PIEvents:OnError(Description, SCODE)
print ("Error",Description,SCODE)
end
function PIEvents:OnInputChange(Index, NewState)
Index = Index + 1
print ("Input " .. Index, "State ",tostring(NewState))
if NewState then
PDelayedEvents [Index]:Start ()
else
PDelayedEvents [Index]:Cancel ()
end
end
function PIEvents:OnOutputChange(Index, NewState)
print ("Output " .. Index, "State "..tostring(NewState))
end
function PIEvents:OnSensorChange(Index, SensorValue)
print ("Sensor " .. Index, "Value "..SensorValue)
end

function PhidgetSetOutput(Nr, mode)
print("PI:setOutputState(" .. Nr .. ", " .. tostring(mode) .. ")")
PI:setOutputState(Nr, mode)
end

luacom.Connect (PI,PIEvents)

function PIDestroy()
PI:close()
PI = nil
PIEvents = nil
PDelayedEvents = nil
collectgarbage()
end

gir.AddScriptResetCallback(PIDestroy)


Any help will be appreciated, the heating system of my house is out of function until this works and it's literally freezing outside!

Question: how does luacom know what kind of parameter setOutputState wants? It should receive a long and a boolean, but I understand lua only works with double floating numbers?

Best regards,

Knut

[Rob H]

Just a thought, but are Phidgets indexed starting from 1 or 0?

[khun]

but that's not the problem. If it was, I should be getting results for the neighbour output, but nothing happens at all (most of the time).

Good point anyway, thanks for the suggestion!

Best regards,

Knut

[Rob H]

Just to clarify - this code worked with G4 and a previous version of the interface kit?

[khun]

I was hoping you wouldn't ask that :-) For "Technical reasons" (read: bad backup routines and a harddisk crash), my previous, working setup is not available anymore...

But yes, I was running this with G4 and I'm quite sure I also there had the Phidget 2.1 COM dll working nicely. And that once I found the command setOutputState, it worked right away.

The example programs from Phidgets work fine, BTW.

Best regards,

Knut

[Rob H]

Are the example programs using COM or some other API?

[khun]

The VBA examples are using the COM interface and work fine. Documentation is in: http://www.phidgets.com/documentation/COM_API_Manual.pdf. But you need to dig in deep in the lua-documentation (I think it was) to find that the correct call for setting OutputState is setOutputState, since it is lua that prefixes the "set"-part of the command.

But it _does_ recognize it, if I try calling e.g. setOutputStats instead, I get an error.

Knut

[Rob H]

Can you post an example of a call to setOutputState?

[khun]

Quite straight forward:

PI:setOutputState(2, true)

and nothing happens, although all outputs are off. Calling

PI:setOutputState(2, false)

doesn't achieve anything more. If I open the InterfaceKit example from Phidgets, I can switch outputs on/off and see the reaction in Girder, so I know the connection between the board and the PIEvents is OK. Girder _reads_ the output status correctly, but doesn't seem to be able to set it...

Best regards,


Knut

[Rob H]

instead of true and false, can you try using 0 and 1 as an experiment?

[khun]

That did the trick! Thank you very much for all suggestions and help!

Here is my updated code:



function PhidgetSetOutput(Nr, mode)
print("PI:setOutputState(" .. Nr .. ", " .. tostring(mode) .. ")")
IntMode = 0
if (mode) then
IntMode = 1
end
PI:setOutputState(Nr, IntMode)
end


Now if I only could kill that ghost...

Best regards,

Knut

[Rob H]

Interesting, can you try one more thing for me?

After sending e.g. PI:setOutputState(2, 1) to turn on an output, can you try PI:setOutputState(2, false).

If that works then I suspect that luacom is translating 'true' as 0xffffffff rather than 0x1. Which is probably correct behaviour but the Phidget interface only accepts 0x1 and is objecting to the other bits being set.

[Rob H]

Oh, I've just had a thought.

Have you tried the Girder watchdog program? I'm not sure whether it will help in this case as it may end up restarting Girder.

[Mastiff]

Watchdog does not do anything to the ghost process, and worse: If Phidgets crashes Girder, Watchdog will not see the crash. I have several times come to the familiar dialougue with restart, quit, send bug report and all that, and Watchdog has been strolling happily along without a bark.

[khun]

You're right on spot, Rob!

PI:setOutputState(Unit, false)

works as it should, but not:

PI:setOutputState(Unit, true)

You have to call e.g.:

PI:setOutputState(Unit, 1)

I tried:

PI:setOutputState(Unit, -1)

which I (after your last suggestion) expected would amount to "true" as I think it is in VB, but that did work, so "true" in luacom is not -1. Or maybe I'm getting something wrong here.

Anyway, my house is now keeping all warm and comfortable again, controlled by Girder :-)

Thanks!

P.S. Mastiff: La oss nå ikke gå altfor langt, det er alltid morsomt å slå svenskene :-)

Knut

[khun]

During my Ghostbusting researches (which haven't gotten me anywhere so far), suddenly the problem of "Installing Phidget libraries" reappeared! And this time I can't get rid of it even after:

- uninstall
- restart of Windows
- reinstall
- restart of Windows

The only good thing is that as long as I'm there when Girder starts and can press "cancel" on the reinstall process, things seem to work just fine!

Any help much appreciated!

Best regards,

Knut

[Mastiff]

This stuff is so messed up I don't even know how to express it! I'm guessing the problem lies on the Phidgets side since Girder's implementation of COM should be pretty standard. Which brings me back to thinking of using the webserver instead. Luckily we're both on the same type of script, where what's called in all the individual scripts is a bunch of functions. So if I (well, nothing wrong in being optimistic...) can figure out how to integrate with the Phidgets webserver, it's only necessary to remove the COM stuff and write new functions. I'm even considering trying out running the Phidgets on a virtal machine with stripped down Windows 2000 and nothing but the Phidgets in. Could that be a solution?

[khun]

As long as something's working steadily, I don't really care how. But I think I'll start by sending some questions to the Phidgets guys and here what they say.

Keep us updated!

Knut