FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the maximum update frequency of the FP-1300

Hello,
I have a fieldpoint unit connected to a CAN bus and I was wondering what the maximum frequency that I can send messages to the fieldpoint is. I have been having some problems with sending signals (via CANalyzer and a CAPL script)  too fast and causing errors on the unit (signaled by a red falshing "can status" light). I believe that I am overflowing the bus with messages.

Now I want to use the fieldpoint to "play back" voltages using the can bus, but I am not sure what resolution (the frequency that I send messages) I can send out at because I am afraid I will simply overflow the fieldpoint unit. My fieldpoint unit is the FP-1300 and FP-A0-210 modules. Thanks!
0 Kudos
Message 1 of 8
(4,042 Views)
Derek H,
The problem probabaly is not only with how fast your are sending your data but how fast you are removing it from you buffer to ouput. Make sure that you are reading data from the 1300 quickly enough so that you don't overflow its buffer. So either increase your "read" rate or decrease the amount of data sent.
 
ChrisC
0 Kudos
Message 2 of 8
(4,029 Views)
Well, essentially, I have CAN messages going to the fieldpoint unit at 250kBaud, and the Fieldpoint just shoots the requested voltages out to some controllers. I dont really know what else there is to change on this thing. Our whole system has to run at that update rate, so thats pretty much locked in (unless you're talking about some other value). I think the problem, like you said, may be that the buffer just overflows. I notice that the overflow light comes on after outputting values to 24 of my 36 voltage outputs at once. I usually have to use a timer to just do 4 at a time, which is annoying.

Also, I have setup my CANalyzer to record CAN messages right off a vehicle and made another configuration to replay them real time in the lab. But, I want to increase the rate at which the controllers send their can messages. Right now its at 2 seconds, and that makes for a very unprecise illustration of CAN activity. I could decrease this rate to something like 100ms but I am afraid that the 24 voltages that I would be outputting these messages to would just get overloaded. Thoughts? (Thanks so far, chris).
0 Kudos
Message 3 of 8
(4,028 Views)
Hey Derek,
Sorry for taking so long to get back to you. Let's here it for long weekends!
 
There was something you said in your last post that I was wondering about: "Fieldpoint just shoots the requested voltages out to some controllers". In my mind I see a fieldpoint bank that consists of a 1300 and ao 210. Your 1300 is connected to your CAN bus and you are transmitting information TO the 1300. This information is the voltage values that are going to be generated by the 210. Is this correct? What do you mean by "controllers"?
 
Also, if I understand correctly the error only occurs when you try to output to more than 24 of the AO channels. What happens if you only send one set of 36 values? In other words, is it the number of channels, or the amount of data?
 
Chris C
0 Kudos
Message 4 of 8
(3,972 Views)
Yes, there is a CAN bus that speaks to the 1300, which also contains a bank of 210 units. These 210 units output voltages. It doesn't really matter that much, but we then connect the outputs to some controllers (using the voltages to simulate signals that a vehicle would normally see under certain conditions). Essentially we are using it to fool our controllers to think that its receiving input from sensors. Anyhow, the error occurs when we try and send a message across the CAN bus (using CANalyzer and the CAPL scripting language) to tell it to update all of the channels on the 4-210 units we have. If we only send 4 signals, we are okay, but as we increase we run into the overflow problem. I am not sure at what exact amount the FieldPoint unit overflows, but since we are trying to rewrite the voltage outputs at least once a second, it ends up meaning a lot of changes for the units. This is what we want to happen:

1) Start program
2) Write initial value to ALL outputs (24) (this is usually where it fails)
3) As signals come in (they dont all come in at the same time), change the voltages on the FP unit to match them (according to the D to A conversion we have decided on)


It seems that if we sort of skip step two, and never write to all the channels IN MASS, then we are okay. I am just wondering if we are going to run into a problem if we try and run step 3 (where the signals update) at a faster rate. Right now, the signals dont change any faster than once every 2 seconds. But this (because it is simulate input from a joystick and other machine information) is a very slow rate to be simulating real life behavior. Therefore, we want to send signals out maybe 2 to 3 times per second, but we dont know if we even can because we are afraid the fieldpoint unit will just overflow every time.

I am very surprised this isn't a well-known specification. Strange. Thanks for your replies so far Chris_C, I appreciate it greatly.
0 Kudos
Message 5 of 8
(3,961 Views)

Derek,

You bring up a great question. I'm going to have to ponder it, but in the meanwhile I've found a spec on the ao 210 for it's max ouput rate. Check out the operating instructions pf 9. It says the max update rate is 200 updates \ s. Again, I'm going to have to ponder the main question, but I thought this might be interesting to you.

 

Chris C

 

0 Kudos
Message 6 of 8
(3,936 Views)
That does indeed help. Perhaps that is the issue. My testing compatriot is gone for the weekend, but hopefully we can see which device is truly a bottleneck. 200 updates per second seems like plenty to me, so I estimate that it is not the 210. But we shall see. Thanks again for the help; as always, you bring excellent information to your posts.
0 Kudos
Message 7 of 8
(3,926 Views)
Hey Derek,
So I think I found out some good info for you. The buffer avaliable on the 1300 is about 64 bytes. That is, it can only pull a maximum of 64 bytes off of the CAN bus and write that info out before it receives more data. Now, you're looking to write to 32, 16 bit (2 byte), channels. That equals 64 bytes right there and that doesn't include the header information for the CAN bus. So that's why we're getting the buffer overflow.
 
Now what can you do about this? Well, one would be not to ever update all channels at once. Spread out the updates across your channels. Next, you can experiment to determine what the maximum sustained rate of incoming messages the 1300 can handle is. You can vary the baud rate of the bus, or vary how many channels you write to at a time. You can then write code to prevent ever going over that limit.
 
If you have questions about to do this with CAN, just post back again.
 
Thanks!
 
Chris C
 
0 Kudos
Message 8 of 8
(3,848 Views)