Custom Software Development

If using ModCom as your host software, it automatically handles all of the critical details of the DAQ Module communications operations in the background, relieving the user of having to be proficient in this subject matter. However, if you are developing your own custom software to communicate with the DAQ Modules, great care must be given to assure that your program conforms to the specific needs of the communications protocol. If your program accepts C++ function calls, it is best to use our pre-written communications functions to communicate with these DAQ Modules. They can be found in the ModCom subfolder called "C_Code".

Transmitting Configuration Commands:

Many of the DAQ Modules need to be configured by transmitting one or more commands to them at start up. A very common mistake is to write code that will transmit each of these commands in succession one right after the other only to discover that the DAQ Module fails to accept these commands on a regular and/or repeatable basis. Here is the reason why. When you write a line of code to transmit a command, your program does not transmit that command immediately. Instead it places those characters into the communications buffer and tells the operating system (OS) to transmit them when it gets a chance. This could be 5mS later, or even 50mS later. And it will vary depending on the current workload of the OS, such as running other programs in the background, processing mouse or keyboard activity from the user, repainting or refreshing the screen, etc.

In the mean time, if you have a subsequent line of code that will transmit a 2nd command, your program simply places the new characters into the buffer right behind the old characters. Then when your OS finally gets around to transmitting, it will transmit both commands in a row. The 1st command will be received successfully by the DAQ Module, but the 2nd command will be transmitted while the DAQ Module is sending back its reception confirmation to the 1st command. So it will be missed entirely.

Therefore when each command is transmitted, it is very important to have your program wait for the reception confirmation before attempting to transmit another command. This will not only assure that the previous command was received, but assure that the DAQ Module is ready to accept another command. You could easily assume that placing a delay in your program after each command transmission would allow the DAQ Module to respond without causing conflicts, but it is not easy to determine the amount of delay required. Even if you are able to hook an oscilloscope up to your host and measure the latency of each transmission, you will see that this latency varies greatly depending on the OS load conditions, and will be unpredictable. Using our C++ communications functions will allow you to easily transmit commands and then wait for and verify the response.

Reading Data from a DAQ Module:

Another reason that it is important to wait for and process the reception confirmation of each command is because those characters will be loaded into the communications buffer at the host and remain there until your program reads it. And this may cause unexpected results. For instance, suppose you transmit a configuration command and fail to take into consideration the reception confirmation which will be coming back. Then later on you transmit a READ command to get data from the module and have your program read the serial port for the results. But the data you get back from the serial port will not be the results of the READ command. Instead, it will be the reception confirmation of the configuration command that was sent earlier. Your host communications buffer is a FIFO type buffer that will hold all of the previous data packets received from the DAQ Module until they are retrieved by your program one by one. So you must read the buffer each and every time you transmit a command to the module so that it remains empty.