VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

CAN error 1074388984 Windows 7

HI,

I have a problem with sending CAN messages on a system controlled by a Windows 7 machine. I know that the patch should solve the problem, but for some reasons NI did not make the patch available for windows 7, so I'm stuck with the impossibility to send all the CAN messages I need. I can send only a certain amount of messages, if I increase the number of messages some will not be sent and the error come out. Is there a workaround for Windows 7 users?

Regards.

 

Luca Solieri 

0 Kudos
Message 1 of 11
(8,200 Views)

Luca,

 

the error that you are seeing shouldn't have to do anything with the host machine. The entire CAN processing is done in the RT engine itself.

Open the VeriStand ini file on the RT system and add the following section and tokens:

 

[NI VeriStand]

CANRead=5

CANWrite=5

CANReadQueueLength=100

CANWriteQueueLength=0

LogCANError=True

 

 

CANRead/CANWrite control the  dt of the timed loop. Their unit is [ms] (5 is in this case 200Hz).

In your case it is important to set the write-queue-length to 0 in order to avoid the buffer overflow error.

 

 

Let me know if that helped.

Tom

 

0 Kudos
Message 2 of 11
(8,194 Views)

Tom,

I know that the source of the error is not in the host machine. The point is that I cannot install the patch from a Windows 7 PC.

 

Anyway I'll try what you suggested. I have one doubt: setting the  writequeue=0 means that I can have lost packets, right?

 

Luca 

0 Kudos
Message 3 of 11
(8,192 Views)

Hey Luca,

there is always the possibility of lost packages anyway, since the default rate of the CAN loops is 200Hz.

As a matter of fact, the CAN loops are not synchronized with the RT engine at all.

Let's assume the RT engine runs at a rate of 1kHz. In that case the outgoing CAN loop only reads each 5th new value from the RT engine.

 

The bottom line is, the more buffer is allocated on the CAN boards, the less frames can be configured/handeled by the board. Setting the queue length to an absolut minimum value will increase the number of possible active frames.

 

Tom

0 Kudos
Message 4 of 11
(8,189 Views)

Hello Luca,

The NI VeriStand 2009 f1 patch should work for your Windows 7 machine.  There were some reports of a problem with the installer detecting that NI VeriStand 2009 was installed on a Windows 7 machine, but there are updated instructions for installing on the download page.  Please let us know if the download or the other recommendations here resolve this issue for you.

 

Regards,

Angela M
Staff Product Support Engineer

0 Kudos
Message 5 of 11
(8,185 Views)

I installed the patch and modified the Veristand.ini as suggested but the error still remains.

Here is an extract of the log:

**********************
Starting NI VeriStand Engine...
Date: 5/21/10
Time: 11:29:40 AM
Engine Version: 2.0.0.1
**********************
System Definition Details
-----------------------------
Name: EngineSim
Version: 1.0.0.211
Description:
-----------------------------
System Channel Count: 4167
Initializing system data...
Target Name: Controller
System Loop Rate: 2000 Hz

Loading channel calibration scales...
29 channel scales loaded.
Compiling CAN messages...
Initializing DAQ resources...
Synchronizing Timed Structures:
PRIMARY_CONTROL_LOOP
MODEL_PARAM_LOOP
TCP_DATA_LOOP
CAN
CAN_WRITE
CAN_STREAM
DATA_PROCESSING_LOOP
WATCHDOG
Controller/Custom Devices/RSim
Controller/Custom Devices/EngineSim
Controller/Custom Devices/FIU
HIL_MODEL MODEL LOOP

Synchronization Timeout: 60000 ms
Launching system CAN loops...
Initializing Primary Control Loop timing source data...
Timing Source: DAQ Timing
Launching asynchronous Custom Devices...
Custom Driver: c:\ni-rt\VeriStand\Custom Devices\RSim\RSim Engine.llb\RSim RT Driver VI.vi Loaded.
Custom Driver: c:\ni-rt\VeriStand\Custom Devices\EngineSim\EngineSim Engine.llb\EngineSim RT Driver VI.vi Loaded.
Custom Driver: c:\ni-rt\VeriStand\Custom Devices\FIU\FIU Engine.llb\FIU RT Driver VI.vi Loaded.
Preparing to start NI VeriStand Engine...
Initializing Primary Control Loop...
Initializing Inline Custom Devices...
Launching model loops...
Primary Control Loop initialization complete.
Primary Control Loop started...
Error creating CAN object: CAN0::STD0xF, code: -1074388831
Data Processing Loop started...
HIL_MODEL model loop started...
Client connect:172.25.10.6
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956
Error sending CAN ID: 15, code: -1074388956

 Any new idea is welcome.

Thanks.

 

Luca

Message Edited by sirluke on 05-21-2010 04:36 AM
0 Kudos
Message 6 of 11
(8,161 Views)

The error code means:

 

Error -1074388831 occurred at an unidentified location

Possible reason(s):

NI-CAN:  (Hex 0xBFF620A1) Too many messages with high transmit rates. The combined timers cannot be accurately maintained. Solutions: Decrease the number of periodic transmissions; Decrease the transmit rate for one or more messages.

 

 

What does your CAN configuration look like? Lots of 1ms channels?

Stephen B
0 Kudos
Message 7 of 11
(8,150 Views)

I don't have 1ms channels.

The CAN configuration is the following (500kbps):

-4 frames @ 200Hz (5ms)

-3 frames @ 50Hz (20ms)

  

The bus load is not even 40%, the hw should be able to handle it. For sure the ECU is able to deal with it.

 

Luca 

0 Kudos
Message 8 of 11
(8,121 Views)

Hello all,

 

When using NI-CAN, if the schedule is dangerous (possibility of bad jitter), NI-CAN returns a warning.  This algorithm is based on an assumption that each CAN Obj requires 1.5ms of overhead time to handle periodic behavior.  If that is the case, we can take the largest period, then determine if the faster CAN Objs will all fit within that time.  If not, then we know the overall schedule can't be met. The error occurs for <1.5ms per object. For example, 6@10ms and 1@9ms returns error (if it takes 1.5ms per object, then 1.5ms*6 =9ms, which does not leave enough time for the 9ms period to be met ) , but 6@10ms and 1@11ms does not. The warning occurs for <2ms per object. For example, 4@10ms and 1@9ms returns warning, but 4@10ms and 1@11ms does not.

 

In your case, I think the error occurs because of the 4@5ms.  Since we need 1.5ms for each frame, this would take a total of 6ms for all 4 frames, violating the 5ms. 

 

Sorry for the long explanation.  Unfortunetely, this is a hardware limitation with NI-CAN hardware.  Our new NI-XNET platform does not have this limitation.

O. Proulx
National Instruments
www.ni.com/support
0 Kudos
Message 9 of 11
(8,110 Views)

The 1.5ms overhead is only for periodic frames? Using a trigger channel would solve the problem?

The NI-XNET hw is a direct replacement for series 2 hw, or is recoding needed?

Thanks.

 

Luca 

0 Kudos
Message 10 of 11
(8,098 Views)