This section covers various issues that will be encountered when writing applications using the intrepidcs API. Click on the question for more information.
When calling or to connect to the device, all the enabled channels on the device are active. Nothing special needs to be done "open" another channel. Calling will get messages on all enabled channels. Looking at the in the message structure for that message, the channel the message occurred on can be determined. When transmitting a message using , the third parameter is the to send the message out on.
The API offers a few different ways to alter the settings in the hardware. Each has their own advantages.
Device specific Get and Set Settings functions:
Each hardware device has a specific function for getting and setting settings with a unique structure breaking out all the settings for that device. The Device Settings Function page has detailed information on the functions and structures. The advantage of this method is access to all the settings of the hardware.
SetBitRate function:
This function gives the ability to set baud rates for any device. This command is not device specific. The same command will work on a ValueCAN 3, Plasma, RAD Galaxy, so on, and so on. The disadvantage is a limitation on the settings that can be configured. This is good for simple baud rate changes for setups that are device independent.
Get and Set Device Parameter:
To set individual parameters the GetDeviceParameters and SetDeviceParameters functions can be used. This function set uses a string of specific parameters to get or set without using a device specific structure. The same parameter strings without regard to the type of device you are connected to. For instance, the string for setting the baud rate on the first CAN channel on a ValueCAN3 and a neoVI Fire are the same.
Regardless if you are trying to send an Extended Frame, High Voltage Wakeup, orISO9141/KW2K init, the key is the Status Bitfield. The Status Bitfield holds extra information for the message. Each bit of this parameter is a toggle for a different parameter. To send a High Voltage Wakeup, you would set the SPY_STATUS2_HIGH_VOLTAG
E bit for your message. For an extended address you would set the SPY_STATUS_XTD_FRAME
for the message you want to have an extended address. SPY_STATUS_INIT_MESSAGE
is set to send an Initialization waveform with a ISO9141 or Keyword 2000 message.
The very first step to working with LIN is to make sure it is enabled on your hardware device. This is done in neoVI Explorer. Please see the hardware documentation for the device to be used on how to do this.
Working with LIN can be done in different ways, so it is important to know how what is needed for the LIN network that is being connected to. Is the application going to act as a Master, Slave, or just spy on the bus? If just spying on the bus is needed, messages can be read like other networks.
The first step to acting as a Master is to enable the Master resistor in the hardware. This is done in neoVI Explorer under the desired LIN channel. This is not needed if the cabling includes the resistor or when operating as a Slave. Below is the setup for a simple Master request with no slave data. Note that the J1850 Spy Message structure is used and the LIN protected ID is in the first data byte.
Master frame no slave Data
Master frame with Slave data
Sending a Slave message is just like sending a Master frame with Slave data. The difference is that the SPY_STATUS_INIT_MESSAGE
bit is not set in the StatusBitField. This bit tells the hardware if the message is a Master frame or a slave frame. When sending a Slave message, it is sent and saved in the hardware. The message will be sent when a Master request is received. Once the request is received, then the Slave data goes out appended to the Master Frame. The same slave data will go out with every Master request, until a new Slave message with updated data is sent from the application to the hardware using the TxMessage function. When reading LIN, the checksum will be in the ACK1 parameter of the message structure.
If the neoVI is removed from the computer or stops responding, most API calls will generate a disconnect error. If you receive a return value from an API call that indicates an error occurred, you must call the GetLastAPIError method. If the error is NEOVI_ERROR_DLL_NEOVI_NO_RESPONSE
then the neoVI has either been unplugged or is not responding.
To recover from this condition follow these steps:
Plug the neoVI back in, or in the case of the neoVI not responding, remove and then plug back in.
Call the ClosePort method.
Call the OpenNeoDevice method using the same parameters are before.
The following API functions will generate the NEOVI_ERROR_DLL_NEOVI_NO_RESPONSE error:
Function |
---|
ScriptReadRxMessage
ScriptReadTxMessage
ScriptWriteRxMessage
ScriptWriteTxMessage
ScriptReadISO15765_2_TxMessage
ScriptWriteISO15765_2_TxMessage