BlitzMax & Phidgets

BlitzMax Forums/BlitzMax Programming/BlitzMax & Phidgets

Kistjes(Posted 2008) [#1]
Hello,
Here is a very specific question. I don't know if anyone at this forum is familiar with Phidget interface boards.
In trying to connect my application with Phidgets electronics (sensors, controls, etc.) for an interactive mixed media installation.
I've done it before with Macromedia Director but for Director was a ready-to-use plugin (xtra) available.
Now I'm writing an interface with the Phidget21.dll.
I made a little progress, in a sence that I can make a connection with an interface board (Phidget I/O card) but I get an "Unhandled Exception: Unhandled Memory Exception Error." I learned from this forum that it has to do something with a wrong parameter definition.

Anyway, is there somebody out there who has experience with using Phidgets in BlitzMax and is he/she willing to help me writing an Phidget interface?

Here is my experiment code:


More info and dll downloads at www.phidgets.com


grable(Posted 2008) [#2]
You need to use "Win32" istead of "C", as the calling convention for dlls is stdcall.


Kistjes(Posted 2008) [#3]
Tried Win32...
It makes no difference using "C" or "Win32"
Same behaviour.
If there is no interface board attached it runs, waits for 3 secs, closes the link end terminates properly the app.
But if there is an interface board attached it runs, finds it immediately, runs the Attach() function, prints "run application" and... pops up the error message.


grable(Posted 2008) [#4]
Win32 is the proper way to go, and you probably need to use it for any callbacks as well.


Kistjes(Posted 2008) [#5]
and you probably need to use it for any callbacks as well.

you mean?


Blueapples(Posted 2008) [#6]
I don't know if this would make a difference, but your callbacks aren't returning anything and they are defined as :Int() in the API declarations. I'm almost positive it's something related to the way the callbacks are declared, because you're not passing anything to the library other than the -1 in PhidgetOpen().

Unfortunatly I don't think there is anyone where who's used that particular piece of hardware.


Kistjes(Posted 2008) [#7]
The -1 parameter is the a notation for the serialNumber of the automaticly found instance of the PhidgetBoard when calling
PhidgetInterfaceKitCreate(gPhidgetHandle)
One can address multiple i/o boards by using this serialNumber, but since I use only one I can use the -1 value.

If you install the Phidget software without having any hardware you can run my program and it will wait for an i/o board to attach. So the declerations seem to work. The problem occurs when a i/o board is attached. Therefor I'm dependent of a forum member who has some Phidget hardware to test.
Unfortunatly I don't think there is anyone where who's used that particular piece of hardware.

It is very interesting hardware to use for games and interactive shows, though.


grable(Posted 2008) [#8]
you mean?

Stick a "win32" after the declaration like in your function pointers.
its worth a try anyway.


skidracer(Posted 2008) [#9]
A long in C on 32 bit hardware is the same as int and is not compatible with BlitzMax long, so you need to change the duration:long to duration:int.

also, for callbacks try the following
Global PhidgetSetOnAttachHandler:Int(phidgetHandle:Int, handler:Int()"C", userDataStruct ptr) "C"
Global PhidgetSetOnDetachHandler:Int(phidgetHandle:Int, handler:Int()"C", userDataStruct ptr) "C"
Function Attach() "C"
	Print "InterfaceKit Attached!"
	gbAttached = True
End Function

Function Detach() "C"
	Print "InterfaceKit Detached!"
	gbAttached = False
End Function


actually your callback parameters are all wrong/ missing compared to the examples in the c api manual so you will need to fix them also


Kistjes(Posted 2008) [#10]
@skitracer: Thanks for taking time reading the c api manual.
actually your callback parameters are all wrong/ missing compared to the examples in the c api manual so you will need to fix them also
If that's so, than how do I fix them? What is the right notation?

Btw. your modifications make no difference in behaviour.

I'm in a strange situation of having
* a BlitzMax community with BlitzMax guru's (yes, that's you guys) but without Phidgets experience,
* a Phidget community who has no experience in BlitzMax,
* a colleque who is a DLL expert but who has no experience with BlitzMax nor Phidgets, and finally
* me, the ignorant, who sees lot's of nice opportunities in the combination of BlitzMax and Phidgets.
But I'm not giving up :)


skidracer(Posted 2008) [#11]

If that's so, than how do I fix them? What is the right notation?



err, have you read the manual ?


Brucey(Posted 2008) [#12]
Oooh, I wonder if you can get this stuff in the UK?

Might be a nice project for when I get back :-)


Kistjes(Posted 2008) [#13]
I asume I'm the only BlitzMax programmer that uses Phidgets but I would like to use this post to keep track of the changes and insights. And by the reaction of Brucey I have the impression I won't be the only one using Phidgets for long ;)

err, have you read the manual ?

should I?
Of course I read it! But did I understand it completely? I don't think so. But I had an appointment with my DLL-guru yesterday and together with him we came up with the following code:



A few minor modifications were made, but the result is still the same. We know for certain the PhidgetOpen() function is the cause of the problem but we have no idea how to solve this. It has something to do with the serialNumber.

This is what I know about it so far:
The phidget21.h file shows to obtain the serial number I have to use a pointer to the variable serial.

int __stdcall CPhidget_getSerialNumber (CPhidgetHandle phid, int *serialNumber);

Then to open the device I use the variable serial itself:

int __stdcall CPhidget_open (CPhidgetHandle phid, int serialNumber);

So I translated that to the following lines of code:
'declaration
Global PhidgetGetSerialNumber:Int(phidgetHandle:Int, serialNumberAddress:Int Ptr) "Win32"
...
'function call
Print PhidgetGetSerialNumber(gPhidgetHandle, Varptr serial)

When debugging this the variable serial does not get a number. That's strange.
One can however overrule this by using -1 in the PhidgetOpen() function to specify the first available device. That doesn't work either.

@brucey: I'm from the Netherlands but I'm sure you can buy this in the UK as well.


skidracer(Posted 2008) [#14]
sorry for being a little short with the info, as you can see your attach and detach callback parameters don't look anything like they do in the following.


also perhaps one thing at a time, i would rip out the callback stuff until you solved your serial number puzzle

#include "stdio.h"
#include "tchar.h"
#include "phidget21.h"
int __stdcall AttachHandler (CPhidgetHandle IFK, void *userptr){
printf("Device attached!\n");
return 0;
}
int __stdcall DetachHandler (CPhidgetHandle IFK, void *userptr){
printf("Device detached! %s\n",userptr);
return 0;
}
int _tmain(int argc, _TCHAR* argv[]){
char mystring[15] = "Successfully!\0";
CPhidgetInterfaceKitHandle ifKit = 0;
CPhidgetInterfaceKit_create(&ifKit);
printf("Device detection active\n");
CPhidget_set_OnAttach_Handler ((CPhidgetHandle)ifKit, AttachHandler, NULL);
CPhidget_set_OnDetach_Handler ((CPhidgetHandle)ifKit, DetachHandler, &mystring);
getchar();
printf("Closing...\n");
CPhidget_close((CPhidgetHandle)ifKit);
CPhidget_delete((CPhidgetHandle)ifKit);
return 0;
}



Kistjes(Posted 2008) [#15]
It works!!!
Thanks to your tip of skipping the attach/detach callback functions. After that I took a closer look at the example code from Appendix IV in the C API manual (the same code as you've just posted) to find out what I was doing wrong.
The result of all that effort is implemented in the code below. It is working code now ;) (To be totally honest; the serialNumber function is still not working.)
Mind you, it is not a program; it is just example code that you can build/run.

The next step I want to make is creating an include file 'phidget.bmx' with a TPhidget type containing all the interfacing with the different Phidget boards (e.g. InterfaceKit, LEDboard, Accelerometer, etc...). If anyone wants to (help me) make a Phidget.mod instead of a phidget.bmx include file I'll be most grateful.





North(Posted 2009) [#16]
Hey Kistjes,

this thread is a year old but the theory and Phidget boards seem very interesting. Have you continued working on this?
I would love to hear about your progress in this.

kind regards

Nicholas


Kistjes(Posted 2009) [#17]
Hi Nicholas,

Phidgets are very interesting if you want to make (interactive) installations for example.
In the past I wrote applications in Adobe Director. Since there is already an interface between Director and the Phidgets boards I didn't need to write any. But I switched to BlitzMAX for several reasons and I wanted to be prepared for any Phidget project.
I haven't had a Phidget project recently, so there is not much of a progress. With the above code I was able to do most of the work. I still need to make a nice Phidget module.
I hope there will be more time in the summer to write a proper module. When it's ready I'll post it in the code archive.


North(Posted 2009) [#18]
Hi Kistjes,

thanks for answering. My aim is to create some kind of semi-automation for my greenhouse. With sensors like PH, EC, humidity, temperatur and maybe(?) the possibility to switch pumping systems and lights on and off phidgets seems to fit that bill.
I need to do alot more reading though because the system has its price especially when i need a lot of sonsoring equipment.

Have you experienced any drawbacks yet i should be aware of?
And do you know if they have some kind of liquid level indicator?

I'd also like to stay within BMX environment but i have no idea about wrapping a DLL so i would depend on your wrapper. How complete is it if i may ask?

Thanks in advance

Nicholas


Kistjes(Posted 2009) [#19]
That's a nice challenge you come up with.
I think you need to be creative with the liquid level indicator part.

This is the status of the BlitzMAX code so far:
* Initialise an I/O interface board.
* Read analog inputs
* Read digital inputs
* Write to digital outputs.
* Changes of the inputs do not yet create an event, so you need to measure the inputs manually (in a loop, if required).

Check the phidget website for all available sensors. USB sensors (like the Ph-sensor) need to have their own interface, which is not implemented yet.

About my experience with the Phidget boards and sensors:
In my Adobe Director days I've done some heavy prototyping with Interface boards, LED-boards, RFID tags etc.
The electronics works great and are very reliable. A true plug'n-play experience.

Drawbacks: the led-board isn't very fast. If you want to fade a bunch of leds you'll experience a frame rate of approx. 10 fps.

My to-do list (or wish-list):
* implement input change events,
* support all phidget boards (led-board, usb sensors,...)
* create an all-in one phidget module.
There is no phidget related project planned yet, I don't know when I will have the time to do this.


wmaass(Posted 2009) [#20]
Kistjes,

Count me in as excited to see a phidget module. I have a board with a number of sensors just lying around. I would love to do something with these.


North(Posted 2009) [#21]
Thanks again Kistjes :)

I think I already have a pretty solid idea how to create a liquid level indicator with help of the IR Distance Sensor.
All in all your statements have encouraged me to go ahead and grab one of these 8/8/8 boards and to start experimenting asap.
I'm just a little weary about using electronics(sensors) in a highly humid environment. A little more reading might enlighten me in this regard.

Have a nice day

Nicholas


Kistjes(Posted 2009) [#22]
@North: Good luck and, please, keep me informed!

@wmaass: be patient ;)


Kistjes(Posted 2009) [#23]
Go ahead, give it a try. Download my Phidget module from this thread.


wmaass(Posted 2009) [#24]
Wow, trying now.