LabVIEW
PICAM SDK, Call Library Function, crashes LV
Solved!
That is the definition in the header file:
PicamParameter_Rois = PI_V(Rois, Rois, 37),
It's a bit of preprocessor magic and you have to look for the property entry you want and then construct the resulting value in Hex.
Take the first parameter and add PicamValueType_ in front of it and look up its value in the list above the typedef enum PicamParameter definition. This value written in Hex notation is VV (prepend 0 to the number if necessary to make it have 2 digits).
Take the second parameter and add PicamConstraintType_ in front of it and look up its value in the list above the typedef enum PicamParameter definition. This value written in Hex notation is CC (prepend 0 to the number if necessary to make it have 2 digits).
Take the third parameter and convert it into hex and this is NNNN (prepend 0 to the number if necessary to make it have 4 digits).
Then concatenate these three values as follows:
0xCCVVNNNN
For the PicamParameter_Rois you then end up with 0x04050025.
Now you can simply create a LabVIEW constant on the diagram and enable the Radix symbol on it (Right Click->Visible->Radix), then set this to Hex and enter that number without the 0x prefix into it. I would personally prefer to actually set the LabVIEW constants to Hex display mode rather than converting above value to Decimal and enter it like that.
Hello,
I am currently studying the SDK that Blokk shared some time ago (thanks a lot for that!). I am completely new in dealing with .dll libraries. I want to understand how to define a function from picam32.dll in LabView. For instance, lets consider the following .vi:
So there is a 'call library function node' which serves as a gate to a function from a library. In this case the function is 'Picam_SetParameterFloatingPointValue', which can be chosen in the field 'Function Nme'. Then we pick up the names of the parameters in the field 'Function prototype'.
In our case these are 'camera', 'PicamParameter', 'temperature'. So we add them in the tab "Parameters":
Then we have to specify type and data type, and this as I understand will accomplish defining a function from .dll in LabView, is that correct?
So the question is where could the Type and Data Type be looked up from. From 'Function prototype' field, e.g. the data type for the parameter 'temperature' is 'double'. But it is not clear if it is 8-byte or 4-byte double. Could you please help me to understand this?
Well aside from pointer stuff you basically chose the most complex function from this API to tackle.
Generally Blokk is right and the according header file will tell you what the correct setting is. This requires of course that you can read and understand C syntax. However the Picam_Parameter functions are special.
Because the function you need to use depends on the value of the first parameter to the macro that defines the PicamParameter enum value.
So if you want to access:
PicamParameter_SensorTemperatureSetPoint = PI_V(FloatingPoint, Range, 14),
You need to indeed use the Picam_GetParameterFloatingPointValue().
And then the definition of that function contains a SDK specific definition piflt that is not contained in the picam.h file but comes from the included pil_platform.h file. That file is unfortunately not attached to the initial post.
Luckily a tiny bit of google magic comes up with this link: https://github.com/areaDetector/ADPICam/blob/master/PICamSupport/pil_platform.h
and in there you see that piflt is indeed simply double.
Hello,
I have been busy implementing GET methods for parameters in LabView. So far I have implemented subVIs for the parameters of the types Integer, FloatingPoint and Enumeration. I stumbled upon an issue when implementing GET-method (subVI) for a Boolean parameter, e.g.
PicamParameter_DisableDataFormatting
Here are some screenshots:
As you can see, LabView crashes. Is there anything I am missing?
Thanks!
Well you use the Picam_GetParameterIntegerValue() function (which is probably right since there is no Picam_GetParameterBooleanValue() but you pass it only a pointer to an uInt8. That is definitely wrong as Picam_GetParameterIntegerValue() is defined to expect a pointer to a piint and just because it is about a boolean value doesn't mean that you can arbitrarly change the dataype of what you pass to the function.
Besides boolean in C is one of the least defined datatypes. The original C standard didn't even know it as a built in type and it only got added in C++. But C++ only requires the value to be able to indicate two states TRUE and FALSE and says explicitly nothing about the size. Most current C++ compilers implement it as 8-bit value but some apply special alignment rules to it that make it use the size of an int32 anyhow when combined in a struct for instance. But a C++ compiler would be perfectly within the standard to use an int32 or even an int64 on 64-bit platforms if it decided so.
C anyhow is pretty unspecific about sizes of its variables in memory. Even integers are just defined to be that a short MUST be >= byte and long MUST be >= short, and a byte should be the smallest addressable unit for the actually used CPU. A C compiler defining byte, short and long to be all 8-bit large would be fully conforming to the C standard, although it wouldn't really be very useful on any modern CPU. That said I have worked a few years ago on a project to validate chips where an embedded CPU was using 4-bit instructions and data bus. So 8-bit isn't the universal standard and wasn't in the time C was invented. You had some CPUs that used 9-bits and the data was generally displayed in octal notation as that fit the 9-bit data bus perfectly.
You shouldn't use int64 for this! It won't crash as there is no possible memory violation but there is a potential for a bogus return value. While LabVIEW most likely will pass in a 64 bit integer set to its default default value of 0 that isn't necessarily a safe assumption to do. The value could be just as well uninitialized (it would be in C programming unless you explicitly set it to 0 before the function call) and the function assuming that it is a 32-bit value will only overwrite the first 4 bytes leaving the 4 higher significant bytes in the 64-bit value unchanged. Then after the call you compare this value to be not-equal to 0 to determine its Boolean status and the bogus bits in the upper 32-bits would never make this value be 0 so leading to a wrong conclusion.
Another recommendation, if you make an explicit Boolean accessor I would also make it return a real LabVIEW boolean instead of an integer. Otherwise you could just leave the Boolean accessor away like the Picam API does.
