Jump to content

Architect question for CAN threads


lraynal

Recommended Posts

Hello LAVA users !

Here is an architect question:

I need to control / read 4 devices with a CAN bus.

Each devices have 4 frames to watch (1 to command the device, and 3 to read)

Actually, I have already some code, which open a "reference" for each frames, and use Occurence to wait for a new frame to read.

If I'm using this code, I will have 4x4 = 16 "threads" (parallel loops in LabVIEW).

Do you think guys, is it a good idea to have so much "threads", knowing that I will have 2 or 3 for the GUI + 1 or 2 for ANA + 1 or 2 for DIO...

Which makes something like 22 threads !!!!

I know (by theory, I've never done that, yet) that CAN is like RS232, I can have a write thread, a read thread, and an analyser thread (the read send to the analyser by Fifo !).

Which solution looks better ???

The first one: almost no new coding, but too many threads perhaps ?

The second one: All the coding to do, but less threads and then less CPU, less memory, ...

What do you think ?

Laurent

Link to comment

QUOTE(lraynal @ Feb 26 2008, 05:15 AM)

Hello LAVA users !

Here is an architect question:

I need to control / read 4 devices with a CAN bus.

Each devices have 4 frames to watch (1 to command the device, and 3 to read)

Of course at some level of complexity you get problems, but not at this level. You may notice that there is not a lot of conversation on this topic. This is because it is not usually a problem. There are extreme cases and choosing the correct architecture is definitely the solution.

Keep in minid that quite a lot of the work is not done by the PC. The DAQ and I/O are configured and then the PC just fires these tasks off. You have a very efficient engiine running on the DAQ board to deal with the gathering of data, and writing to and reading from the I/O. The PC can't keep pace with data rates greater than 1KHz on its own clock. The whole point of PC based DAQ hardware is to enable these functions without causing hardship for the PC.

The general principle is to set up your loops so that you don't repeatedly configure and release DAQ resources. For a DAQ operation you would group and configure the board resources outside the loop, and inside it you perform the read and write operations. As long as the loop is running the hardware has only to do the work it was optimized to do and the PC only the work it was designed to do. An example of a wrong-headed design would be to put a single point acquisition in side a loop and run it over and over again. Instead you might run a buffered acquisition and sample the buffer periodically while the acquisition continues uninterrupted.

This principle is followed within the Express VIs, other higher level VIs, and other code you may copy for reuse. You only need to concern yourself with how this is done if you can't locate the exact code you need and you must create it yourself. Reading and writing using some add on hardware is what this whole business is about so you can generally find what the code you need already in use.

There are some general guidelines about what operations should be placed inside a loop and what should not. You should become familiar with these.

Mike

Link to comment

QUOTE(lraynal @ Feb 26 2008, 05:15 AM)

Firstly, let me apologise for not answering this sooner - I had sent you a direct replay email, but my outgoing smtp server seems to only let me through in my home state :) Anyway, this is what I said:

QUOTE(crelfs_lost_email)

'Day Laurent,

I don't think there's a problem having so many parallel "threads" - LabVIEW is really good at handling that sort of stuff. As long as the thread components aren't resource hungry (eg: they have significant idle times or are event driven) then it should be fine. One thing I'd look into if I were you is maybe breaking some of the components out into separate engines, and then using user events to trigger when something significant happens. I can get one of my guys to send you an example of this once I get to California - we use this architecture a lot when we have multiple loops, and it's a great one-to-one, one-to-many, many-to-one or many-to-many architecture, and the different action engines can be in different VIs, within one VI, or a mixture of each. I'm not saying that it's specifically good for your application, but it's certainly worth considering. It's a very under-used technique in LabVIEW, but can be very powerful.

LVx

- I haven't played with it yet, but it might be appropraite for what you need. I'll be spending some time in the next couple of months assessing it myself.
Try a LAVA search for LVx (it was created by Norm Kirchner)
.

cheers mate,

Chris
Link to comment

G'Day as well Chris !

I will have a look at the architecture example and see if it reach my goals !

But from what you said, I can have "almost" as many threads as I want, which permits me to keep the CAN functions I have, and ameliorate them only !

I will probably have soon other questions about CAN, but let see that later !

Thanks a lot for your answer, tthanks as well Mike for your's,

Cheers mate,

Laurent

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.