Using National Instruments' DAQmx via C++, I would like to present a list of possible physical trigger inputs available on the system to the user.
I can set a task to start on an external trigger by calling something like
char* trigger_source = "/Dev1/PFI0";
DAQmxCfgDigEdgeStartTrig(taskAO, trigger_source, DAQmx_Val_Rising);
Is there a way to get a list of the valid values for trigger_source? I have found DAQmxGetSystemInfoAttribute(DAQmx_Sys_DevNames, , ) to get a list of the devices available in the system, and I know that DAQmxGetDevDILines() and similar functions can give me lists of some of the types of ports on a device. However, I have found nothing that returns the PFIs.
If a list cannot be obtained, is there a sane way to test whether a given guessing string like "/Dev%d/PFI%d" is a valid trigger source?
There are two ways:
Dynamically on-demand
Guess-check-cache-query
Dynamic
You can build this list, but not with a single call into the driver. Use a combination of these properties:
DAQmxGetDevTerminals(const char device[], char *data, uInt32 bufferSize) which returns the PFI lines as well as internal terminals. It doesn't return any of the I/O terminals (like ai0).
DAQmxGetDevAIPhysicalChans(const char device[], char *data, uInt32 bufferSize) which returns the channel terminals for the AI subsystem; there are similar calls for the other DAQ subsystems.
DAQmxGetDevAnlgTrigSupported(const char device[], bool32 *data) which returns whether the device supports triggering from analog signals.
DAQmxGetDevDigTrigSupported(const char device[], bool32 *data) which returns whether the device supports triggering from digital signals.
DAQmxGetDevAITrigUsage(const char device[], int32 *data) which returns what trigger types the AI subsystem can use; there are similar calls for the other DAQ subsystems.
Cached
You could also create a dummy task and preview each terminal and trigger type combination.
You won't need to run the task, just "verify" it, which will prompt the driver to run its rules system on those settings and return an error if that configuration is not supported. If you cache these in memory or a file (or a DB or whatever), it might be easier to query that instead of the driver.
DAQmxTaskControl (TaskHandle taskHandle, int32 action) which moves the task in the DAQmx state model. Using DAQmx_Val_Task_Verify for the action parameter will verify that all task parameters are valid for the hardware.
Related
I have a setup with two regular displays and three projectors connected to a windows pc. In my win32 program I need to uniquely identify each monitor and store information for each such that I can retrieve the stored information even after computer restart.
The EnumDisplayDevices seems to return different device orders after restarting the computer. There is also GetPhysicalMonitorsFromHMONITOR which at least gives me the display's name. However, I need something like a serial number for my projectors, since they are the same model. How can I get such a unique identifier?
EDIT: This is the solution I came up with after reading the answer from user Anders (thanks!):
DISPLAY_DEVICEA dispDevice;
ZeroMemory(&dispDevice, sizeof(dispDevice));
dispDevice.cb = sizeof(dispDevice);
DWORD screenID;
while (EnumDisplayDevicesA(NULL, screenID, &dispDevice, 0))
{
// important: make copy of DeviceName
char name[sizeof(dispDevice.DeviceName)];
strcpy(name, dispDevice.DeviceName);
if (EnumDisplayDevicesA(name, 0, &dispDevice, EDD_GET_DEVICE_INTERFACE_NAME))
{
// at this point dispDevice.DeviceID contains a unique identifier for the monitor
}
++screenID;
}
EnumDisplayDevices with the EDD_GET_DEVICE_INTERFACE_NAME flag should give you a usable string. And if not, you can use this string with the SetupAPI to get the hardware id or driver key or whatever is unique enough for your purpose.
Set this flag to EDD_GET_DEVICE_INTERFACE_NAME (0x00000001) to retrieve the device interface name for GUID_DEVINTERFACE_MONITOR, which is registered by the operating system on a per monitor basis. The value is placed in the DeviceID member of the DISPLAY_DEVICE structure returned in lpDisplayDevice. The resulting device interface name can be used with SetupAPI functions and serves as a link between GDI monitor devices and SetupAPI monitor devices.
I have a setup with two regular displays and three projectors connected to a windows pc. In my win32 program I need to uniquely identify each monitor and store information for each such that I can retrieve the stored information even after computer restart.
The EnumDisplayDevices seems to return different device orders after restarting the computer. There is also GetPhysicalMonitorsFromHMONITOR which at least gives me the display's name. However, I need something like a serial number for my projectors, since they are the same model. How can I get such a unique identifier?
EDIT: This is the solution I came up with after reading the answer from user Anders (thanks!):
DISPLAY_DEVICEA dispDevice;
ZeroMemory(&dispDevice, sizeof(dispDevice));
dispDevice.cb = sizeof(dispDevice);
DWORD screenID;
while (EnumDisplayDevicesA(NULL, screenID, &dispDevice, 0))
{
// important: make copy of DeviceName
char name[sizeof(dispDevice.DeviceName)];
strcpy(name, dispDevice.DeviceName);
if (EnumDisplayDevicesA(name, 0, &dispDevice, EDD_GET_DEVICE_INTERFACE_NAME))
{
// at this point dispDevice.DeviceID contains a unique identifier for the monitor
}
++screenID;
}
EnumDisplayDevices with the EDD_GET_DEVICE_INTERFACE_NAME flag should give you a usable string. And if not, you can use this string with the SetupAPI to get the hardware id or driver key or whatever is unique enough for your purpose.
Set this flag to EDD_GET_DEVICE_INTERFACE_NAME (0x00000001) to retrieve the device interface name for GUID_DEVINTERFACE_MONITOR, which is registered by the operating system on a per monitor basis. The value is placed in the DeviceID member of the DISPLAY_DEVICE structure returned in lpDisplayDevice. The resulting device interface name can be used with SetupAPI functions and serves as a link between GDI monitor devices and SetupAPI monitor devices.
I have some card, wanted to get ATR from it (using method from some SDK).
Implementation looks like this:
unsigned char ATR[128]={0};
int len=33;
int maxlen=33;
ret = sd7816_ATR(0,1,ATR,len,maxlen,1);
first, second and last parameters to sd7816_ATR function should be like that.
The length fields I tried changing to different values, including 0 but no help.
My concern is the ATR string I am sending is empty in the beginning, and I am expecting
something to get written in it after the call finishes (which actually returns success).
But after call ATR is still empty .. What can be going wrong here?
(I want to find out if card is of ISO/IEC 14443 or ISO/IEC 7816 type).
You are trying to receive an ATR for a command specific for a ISO/IEC 7816-3 contact card. In this particular case, that's requested from a (SIM form) SAM card reader. However, you are trying to read out the contactless based reader.
Now contactless cards do not have an ATR. Some cards do have an ATS (i.e. ISO/IEC 14443 Type A cards), but that should be requested by a similar 14443 SELECT command. Some cards, particularly Type B cards, contain an EF.ATR to make up for the lack of (space within the) ATR. Still, an ATR/ATS has only limited functionality for identifying cards.
ISO/IEC 7816 is comprised of several parts: parts 1 to 3 describe contact cards and 4 and higher describe the Application level APDU commands and file structure of processor cards. If your contactless card implements ISO/IEC 7816-4 then you can - in general - also directly use the PCSC interface to send and receive APDU's to/from the card.
In general readers are for contact or contactless only. If you have a reader which contains both contact and contactless operation then in general they will show up as two different readers in the operating system. So in general, if you know the reader, you know if the card is a contact card or contactless card.
SAM slots may not be identified as readers by the operating system - you may only be able to access them using a low level interface. They are mainly used as a secure storage of keys from the terminal/inspection system/interface device or whatever the name is of the system that reads out the card.
I have been searching all over the net trying to find some example code to see how to listen for sms and read it. I am new to at commands so I am trying to see some examples. My intentions is to listen for sms and read to content. If the message contained the word: 'forward', I want it to run a certain function. I am using a seeedstudio GPRS v1.4 shield with my arduino uno.
I found a library but I am confused on the readSMS() function. The library is found here: https://github.com/Seeed-Studio/Seeeduino_GPRS.
I have the current code:
GPRS gprsTest(8,7,9,9600,"1818XXXXXXXXX");//TX,RX,PWR,BaudRate,PhoneNumber
void setup() {
Serial.begin(9600);
gprsTest.preInit();
delay(1000);
while(0 != gprsTest.init()) {
delay(1000);
Serial.print("init error\r\n");
}
}
void loop() {
//nothing to do
gprsTest.readSMS();
}
My problem is I am not sure of what to put in the parameters for the readSMS function.
According to the api the function takes a int, string, and another int.
int readSMS(int messageIndex, char *message, int length);
Any ideas? Not really any documentation on receiving sms
I am not familiar with Seeed-studio (whose comments in header files are not maintained very well as well, to give you some help) but here is the basic idea:
The received text messages are stored on independent indexes on the selected message memory (SIM or phone which will be modem in your case). New messages usually take the smallest unused index (indexes starting from 1).
There are two methods to detect a new SMS
1) Modem sends a string on output port to indicate new SMS (like an interrupt)
2) You have to read the count of unread messages yourself (polling)
These methods require a knowledge of hardware dependent AT commands. If you want to understand/learn what's going on, give AT commands CMGR and CMGF a read
That said, the information you have explicitly asked for can be found in the function readSMS of gprs.cpp.
messageIndex is the index of selected memory where the message is stored.
*message is the buffer the message will be read into.
length is the length of bytes to be read.
The return status is always 0 (not a good strategy).
I would recommend distinguishing between read and unread messages using custom code. It depends upon your application
I'm currently building a robot which has some sensors attached to it. The control unit on the robot is an ARM Cortex-M3, all sensors are attached to it and it is connected via Ethernet to the "ground station".
Now I want to read and write settings on the robot via the ground station. Therefore I thought about implementing a "virtual register" on the robot that can be manipulated by the ground station.
It could be made up of structs and look like this:
// accelerometer register
struct accel_reg {
// accelerations
int32_t accelX;
int32_t accelY;
int32_t accelZ;
};
// infrared distance sensor register
struct ir_reg {
uint16_t dist; // distance
};
// robot's register table
struct {
uint8_t status; // current state
uint32_t faultFlags; // some fault flags
accel_reg accelerometer; // accelerometer register
ir_reg ir_sensors[4]; // 4 IR sensors connected
} robot;
// usage example:
robot.accelerometer.accelX = -981;
robot.ir_sensors[1].dist = 1024;
On the robot the registers will be constantly filled with new values and configuration settings are set by the ground station and applied by the robot.
The ground station and the robot will be written in C++ so they both can use the same struct datatype.
The question I have now is how to encapsulate the read/write operations in a protocol without writing tons of meta data?
Let's say I want to read the register robot.ir_sensors[2].dist. How would I address this register in my protocol?
I already thought about transmitting a relative offset in bytes (i.e the relative position in memory inside the struct) but I think memory alignment and padding may cause problems, especially because the ground station runs on a x86_64 architecture and the robot runs on a 32-bit ARM processor.
Thanks for any hints! :)
I'm also going to suggest Google Protocol Buffers.
In the simplest case, you could implement one message RobotState like this:
message RobotState {
optional int32_t status = 1;
optional int32_t distance = 2;
optional int32_t accelX = 3;
...
}
Then when the robot receives the message, it will take new values from any optional field that is present. It will then reply with a message containing the current value of all fields.
This way it is quite easy to implement field update using the "merge message" functionality of most protobuf implementations. Also you can keep it very simple at start because you only have one message type, but if you need to expand later you can add submessages.
It is true that protobuf does not support int8_t or int16_t. Just use int32_t instead.
I think the Google protocol buffers are an excellent session/presentation layer tool to use. Actually, Google protocol buffers do not support the syntax I am thinking of. So, I will change this part of my answer to recommend XSD by Code Synthesis. Although it is primarily used with XML, it supports different presentation layers such as XDR and may be more efficient than protocol buffers with large amounts of optional data. The generate code is also very nice to work with. XSD is free to use with OpenSource software and even commercial use with limited message structures.
I don't believe you want to read/write register sets at random. You can prefix a message with an enum that denotes a message such as, IR update, distance, accel, etc. These are register groups. Then the robot responds with the register set. All the registers you've given so far are sensors. The write ones must be motor control?
You want to think about what control you want to perform and the type of telemetry you would like to receive. Then come up with a message structure and bundle the information together. You could use sequence diagrams, and remote procedure API's like SOA/SOAP, RPC, REST, etc. I don't mean these RPC frameworks directly, but the concepts such as request/response and perhaps message that are just sent periodically (telemetry) without specific requests. So there would be a telemetry request from the ground station with some sort of interval and then the robot would respond periodically with unsolicited data. You always need a message id (enum above), unless your protocol is going to be stateful, which I would discourage for robustness reasons.
You haven't described how the control system might work or if you wish to do this remotely. Describing that may lead to more ideas on the protocol. I believe we are talking about layers 5,6,7 of OSI. Have fun.