First steps with PCI-8516

[JB]

---

O_Proulx a écrit :

Hi JB,

However, you can open multiple sessions on the same interface

---

The application is a testbench and the device is a motor. The messages during the test sequence depend on the result of previous tests. Therefore, it will be necessary to open and close several sessions of different types during the test. Furthermore, without a message every Xms, the device enters a default mode.

My idea is following :

1) Before executing the test sequence, start a "watchdog" session

2) During the test sequence, start/stop the needed session

3) Once the test sequence is finished, stop the "watchdog" session

According to my tests, it is not allowed to start a new session while another one is still running on the same interface. How can I best program my application ?

I really appreciated your help !

[JB]

Back from holidays, I will summarize the open questions :

1. With a signal single point session, is there a way to know if the message was sent by the slave ?
2. Is there a way to start a new session while another one is still running on the same port ? Or how can a kind of watchdog (to avoid the slave to enter a default state) be best implemented ?

Many thanks in advance

[GPIB_Guru]

With a Signal, Single-point session, you can still do the XY read and get the timestamp. You do not need to have an XY session to do this.

You cannot create a new session while one is running, but you can start and stop open sessions, so if you can open all required sessions and then just start/stop them when necessary, that should work.

[O_Proulx]

Hi JB,

1. 

I would suggest using an XY session.  When calling read XY, you will get the signal value along with the timestamp associated with that signal value.  You should only get new signal values, which means that your slave has responded.

2. 

LIN usually works on schedules.  These schedules should be defined in your LDF.  If you open a session with a specific schedule (ie.  Send Frame1 @ 10ms), then the XNET interface will continuously send Frame1 @ 10ms until you stop the session.

You can create multiple sessions on the same interface.  However, you cannot create a new session on an interface that is already running a session.  You need to create all your sessions before you start any of them.  Or, you need to stop a session in order to create new one on the same interface.  How long will your slave wait until it gets into the default state?  What happens to your slave when it enters default state?  Why do you not want your slave to enter default state between tests?

[JB]

1. I'm really surprised that there is no way to differentiate a slave's answer from a "pseudo" answer with the default LDF values when usign a Signal Input session ! Would it be that complicated or even impossible to implement ?

2.

    a) As you can imagine, the LDF was edited for the normal function when the slave is mounted in the vehicle. During the production test, several messages that are not part of any schedule have to be sent. Many messages must be sent only once (write to EEPROM...) Furthermore, the sequence of the messages is unpredictable because it depends on the behavior of the slave. This makes it very difficult to configure all the schedules at the beginning of the test sequence.

    b) The timeout of the slave depends on the type (eg 200ms). After power up or entering the default mode, the slave must be initialized. The test cycle is too short to repeat this.

With an USB LIN interface this "watchdog" can easily be implemented with a parallel timed loop which periodically sends an unknown message to the slave.

Any hints are really welcome

[O_Proulx]

Hi JB,

1.  Single Point data always gives you the latest value of the signal.  It should always return a double value for the signal.  If there is no value received for the signal yet, we output the default.  This is consistent with HIL type of tests where there is some sort of "model" running.  If we would output some value like infinity in the case of a "not yet received" value, we would break this kind of model implementation (since the model assumes a valid value everytime, no matter what is actually on the bus).  What was proposed earlier is that you "implement" this workaround yourself by setting the default value in your database to something like infinity (which your slave will never output) and you make your application check for that.

Can you let me know why the XY suggestion does not work for you?

2.

"several messages that are not part of any schedule have to be sent"

You could create schedules that runs once that contains only 1 message.  When you select this schedule in the master, it will only run the shedule once, which means it will only transmit that frame once on the bus.

Schedules are different than sessions.  You can create one session with all the frames in your LDF.  If you have different schedules configured in your LDF, you can dynamically change which schedule you will use (with a single session).  You can make sure the schedules only contain specific frames you want to send.

I hope that helps.     

[JB]

Can you let me know why the XY suggestion does not work for you?

Nothing wrong about XY. I'm just trying to understand why the read VI has no "slave/default answer" boolean output.

What was proposed earlier is that you "implement" this workaround yourself by setting the default value in your database to something like infinity (which your slave will never output) and you make your application check for that.

This is indeed easy to implement.

You could create schedules that runs once that contains only 1 message.  When you select this schedule in the master, it will only run the shedule once, which means it will only transmit that frame once on the bus.

How can I combine these numerous and unpredictable "run once" messages with the periodic "watchdog" message which must be sent during the whole test sequence ?

Sorry for all my questions and thank you very much. The title of the post says all !

[GPIB_Guru]

---

@JB wrote:

Can you let me know why the XY suggestion does not work for you?

Nothing wrong about XY. I'm just trying to understand why the read VI has no "slave/default answer" boolean output.

How can I combine these numerous and unpredictable "run once" messages with the periodic "watchdog" message which must be sent during the whole test sequence ?

---

1) Have you tried to use the XY read w/ the single-point session? You can then use a 0-timestamp to indicate the no slave/default answer output if you want. It is available.

2) The 8516 runs LIN like the LIN bus is supposed to run. The specification is based on schedules. What is probably best is to create multiple "run once" schedules that just send the single numerious and unpredictables messages (i.e., if you need to send ID 8 unpredictably, you would create a run-once schedule that just transmits ID 8). You run your normal schedule and when 8 needs to be send, you queue up the schedule change to the new one - the run once should run (once!) and then the original run continuous schedule should restart automatically. With this, you would just send your sporadic type of messages as needed.

Other options would be to actually use the Sporadic features of LIN and combine IDs into a Sporadic schedule entry (I don't know how much control you have over your bus and the scheduling). With a Sporadic entry, the master (and only the master) and list a number of IDs that would be sent in a single time slot.. If none of them have any new data in the output queue/table then nothing is send during that time slot. If one or more of the IDs have data, the highest priority one would be sent in the time slot. The next highest one would be sent the next time the time slot comes up in the schedule.

[JB]

---

GPIB Guru a écrit

2) The 8516 runs LIN like the LIN bus is supposed to run. The specification is based on schedules. What is probably best is to create multiple "run once" schedules that just send the single numerious and unpredictables messages (i.e., if you need to send ID 8 unpredictably, you would create a run-once schedule that just transmits ID 8). You run your normal schedule and when 8 needs to be send, you queue up the schedule change to the new one - the run once should run (once!) and then the original run continuous schedule should restart automatically. With this, you would just send your sporadic type of messages as needed.

---

This sounds very interesting. Unfortunately there are still some uncertainties (and other may arise later) in my XNET beginner's brain !

Please correct :

1. In the LV code, the first thing to do is to open a session.
2. The signals/frames input array of a session must contain all signals/frames that will be used by the schedules.
3. An In session acts like a Header Frame in the CAN Frame API and an Out session like a Full Frame. (???)
4. Only one session can be opened at a time on a interface.
5. In a session, schedules are used to communicate.
6. Schedules can be started and stopped while the session is running.
7. Several schedules can run simultaneously in the same session.

In my application :

1. I need to send a "watchog" during the whole test sequence to avoid the slave to enter in the default state.
2. This can be done by a specific schedule that runs continuously.
3. The test sequence uses numerous messages that are sent only once. Some of them require an answer from the slave (eg read status), others don't (write something to slave's EEPROM).
4. This can be done by "run once" schedules with a single message.

Is there an example that shows this concept ?

Sorry for my (too) many questions and thanks to bring some light in my nebulous brain !

I have to take the decision between programming the application with XNET or CAN Frame API in a very near future.

[O_Proulx]

Hello JB,

These are good questions.

1. In the LV code, the first thing to do is to open a session.

Yes.

1. The signals/frames input array of a session must contain all signals/frames that will be used by the schedules.

Not necessarily.  Only the signals and frames you care about.

1. An In session acts like a Header Frame in the CAN Frame API and an Out session like a Full Frame. (???)

No.  An input session will read data from the bus and return it to the API. 

In LIN, the master always puts the header on the bus.  The slave or the master can put the data on the bus.  The first thing you need to decide is if your interface will be a master.  Lets say it is a master for now. 

If you open an input session with ID1, and call start, the interface will use the default schedule in your database and run that schedule (since you are the master!).

If this schedule has ID1 in it, the master (the interface) will transmit the ID1 header on the bus.

Depending on your bus, the master itself can write data for ID1.  A slave can also write data for ID1.  Lets say in this case that a slave is writing data for ID1, that is the data you will read when you call read for this input session.

If the master is actually writing data for ID1, then you need to create an output session, with ID1 in the list.  Make your interface the master and call write.  By calling write, the master will select the default schedule and run it.  If ID1 is in the schedule, the interface will write out the header and then write out the data for this ID from the data you provided in the write call.

Let me know if that makes sense...

1. Only one session can be opened at a time on a interface.

No, you can create multiple sessions on the same interface.  You need to create all your sessions before you start any of them though.

1. In a session, schedules are used to communicate.

A session is the NI-XNET API paradigm for handling what you want your interface to do.  The schedules is a LIN specification detail.  The XNET API lets you control the schedules through the sessions.

1. Schedules can be started and stopped while the session is running.

In LIN, I'm not sure you can stop a schedule.  You can change schedules.  Calling STOP on the session will stop the interface from communicating, effectively stopping the schedule.  I hope that I'm making the distinction from what is the XNET API and how it controls aspects of the LIN bus... 

1. Several schedules can run simultaneously in the same session.

No.  Only one schedule can run on the LIN bus at a time, so the session will only let one schedule be active.  Actually, one interface (which can have many sessions) should only let a single schedule be active at any point...