Starting user programming on a work related project

[dsabene]

Hi All!

First things first, I am super new to LabVIEW although I would consider myself knowledgeable on some parts of what LV is used for. My issue still is how novice I am at programming in LV.

Background:

I work for an automotive electro-mechanical switch maunfacturer and we are developing a portable device that is to be used as a tester for switches that are ready for final testing. Currently, our test engineers utilize NI PXI Systems which means they use much of the NI-DAQ library and TestStand to sequence through their test plans.

Situation:

What we are trying to accomplish is creating our own interfacing with the device under test whether it is CAN/LIN or whatever. Essentially we want to be able to replace the PXI System and run the same test sequences that are already being used.

Question:

Is this feasible? I understand the vastness of the types of PXI modules that are available but I am trying to minimize what we use already into one system or library if you will. Please feel free to let me know how you all feel I am trying to wrap my head around a topic that is very new to me so bear with me!

Dennis

[stevem181]

Hi Dennis,

Have you talked to your Test Engineers about this project?

They should should have a good idea of how feasible it is to adapt their code to your purpose.

steve

[dsabene]

---

@stevem181 wrote:

Hi Dennis,

Have you talked to your Test Engineers about this project?

They should should have a good idea of how feasible it is to adapt their code to your purpose.

steve

---

Steve,

I an sure that we can adopt the actual code for testing, I guess I am unsure of the level of complexity with the PXI system. I need to essentially replace that system and it's purpose. How would I do that?

[RTSLVU]

---

@dsabene wrote:

---

@stevem181 wrote:

Hi Dennis,

Have you talked to your Test Engineers about this project?

They should should have a good idea of how feasible it is to adapt their code to your purpose.

steve

---

Steve,

I an sure that we can adopt the actual code for testing, I guess I am unsure of the level of complexity with the PXI system. I need to essentially replace that system and it's purpose. How would I do that?

---

Without knowing details of the hardware you are testing and the test(s) to be performed, it is impossible to recommend test equipment.

But one of the most universal pieces of test equipment I use is the HP/Agilent/Keysite 34971A or 34972A and the appropriate module. http://www.keysight.com/en/pd-1756491-pn-34972A/lxi-data-acquisition-data-logger-switch-unit?cc=US&l...

Also NI has stand alone CAN bus interfaces 

[Ben]

---

@dsabene wrote:

---

@stevem181 wrote:

Hi Dennis,

Have you talked to your Test Engineers about this project?

They should should have a good idea of how feasible it is to adapt their code to your purpose.

steve

---

Steve,

I an sure that we can adopt the actual code for testing, I guess I am unsure of the level of complexity with the PXI system. I need to essentially replace that system and it's purpose. How would I do that?

---

"The first step invloved in solving a problem is to clearly define what the problem is." (Ben Rayner somewhere back in the NI Forums)

Up to this point you hve not defined what your portable tester will do.

Start by creating a list of all of the checks and measurements the portable tester will need to do. That will rule out/in hardware ( i.e. switch time may require a scope, etc).

Share those requirements here and we may be able to offer more concrete suggestions.

Ben

[dsabene]

---

@Ben wrote:

"The first step invloved in solving a problem is to clearly define what the problem is." (Ben Rayner somewhere back in the NI Forums)

Up to this point you hve not defined what your portable tester will do.

Start by creating a list of all of the checks and measurements the portable tester will need to do. That will rule out/in hardware ( i.e. switch time may require a scope, etc).

Share those requirements here and we may be able to offer more concrete suggestions.

Ben

---

Ben,

I am sorry I am being vague I am also unsure of what exactly a PXI system does from a testing standpoint. My knowledge is limited as I am used to using ATE to perform board testing. What I need to test is finalized products for functionality. As I work in automotive switching many are LIN/CAN communication but I also have analog and digital that will need to be tested as well.

From a broader point, I need to be able to interface a product to my custom device and be able to test mainly button pushes at the same time of getting some voltage and current draw. Does this make more sense? Please let me know.

Dennis

[Ben]

If you are familiar with ATE then are safe in assuming you have an idea what the ATE is doing in the testing you have done previously?

Eventually to fully answer if you can do EVERYTHING we will have to know what everything IS.

Assuming (dangerous!) that have an idea of the tests you will need to implement I sugget you start with a simple and then an extreme example that beween the two Use Cases will let us explore IF you can do what you want.

I'll get you started but to get the answer you need, you will have to fix what I have wrongfully speculated.

1) Test if Switch Operates.

After making the required connections the Operator will click the "Test Switch Open" Button.

The determine if the input from the switch is high usinga digital input channel where anything over 10 vlots is concidered a "High" and if satisfied the application will light the "Switch Open OK" light.

The operator will then click the "Test Switch Closed" button.... blah blah blah ... done with that test.

In the above Use Case we can red between the lines that your interface is a digtial input and you just need to makes sure the switch will switch when actuated etc.

2) Test blinker switch on the collum

After the operator plugs into the CAN bus interface the operator selects the "Blinker Swith Test" at which time the appropriate CAN packets for the blinker will be read and dispalyed as "Actuated" "or "Off"...

So start with the simple stuff and keep n mind the big picture. Break it down into challenges and investigate each challenge as the come up.

I can not commit to help too much more on this topic. Extracting Use Cases, and defining requirements is what I do for a living and I will not "give away the shop".

Edit:

From waht you have shared I can say that LabVIEW can most likely do the job. What hardware will be required and how to implement each version and interface type is still an open question. NI Sales can help by suggesting hardware that may be useful. You may want to give them the chance to learn about you application and offer to sell you some hardware.

Ben

[dsabene]

---

@Ben wrote:

If you are familiar with ATE then are safe in assuming you have an idea what the ATE is doing in the testing you have done previously?

Eventually to fully answer if you can do EVERYTHING we will have to know what everything IS.

Assuming (dangerous!) that have an idea of the tests you will need to implement I sugget you start with a simple and then an extreme example that beween the two Use Cases will let us explore IF you can do what you want.

I'll get you started but to get the answer you need, you will have to fix what I have wrongfully speculated.

1) Test if Switch Operates.

After making the required connections the Operator will click the "Test Switch Open" Button.

The determine if the input from the switch is high usinga digital input channel where anything over 10 vlots is concidered a "High" and if satisfied the application will light the "Switch Open OK" light.

The operator will then click the "Test Switch Closed" button.... blah blah blah ... done with that test.

In the above Use Case we can red between the lines that your interface is a digtial input and you just need to makes sure the switch will switch when actuated etc.

2) Test blinker switch on the collum

After the operator plugs into the CAN bus interface the operator selects the "Blinker Swith Test" at which time the appropriate CAN packets for the blinker will be read and dispalyed as "Actuated" "or "Off"...

So start with the simple stuff and keep n mind the big picture. Break it down into challenges and investigate each challenge as the come up.

I can not commit to help too much more on this topic. Extracting Use Cases, and defining requirements is what I do for a living and I will not "give away the shop".

Edit:

From waht you have shared I can say that LabVIEW can most likely do the job. What hardware will be required and how to implement each version and interface type is still an open question. NI Sales can help by suggesting hardware that may be useful. You may want to give them the chance to learn about you application and offer to sell you some hardware.

Ben

---

Ben,

I can say that I feel you are answering my question but I can see now how wague I have been. I have set a meeting with one of our senior test engineers to go over a test setup. I will most likely come back to this topic with more detail. Again I am essentially trying to use the same code the test engineers currently use but eliminate the PXI systems that they use.

Dennis

[BoKnows]

Adding on to what Ben has already stated, I'm a bit confused as to what it is you're seeking to "solve" with all of this.

If you're currently using PXI, it's likely you're using LabVIEW to interface with the PXI.  If you want to use the same code, it's likely you'd have to remain with the PXI.  Otherwise, you'd be changing your code to handle the hardware change.  If you already have the PXI system, you'd have to spend money to replace that hardware with something else.  Are you looking to duplicate the test system and are concerned about the cost of the system?  If not, I can't see how this would provide a cost benefit.  I can only see form factors.

It sounds like you're going to need hardware to talk to both CAN and LIN.  You also potentially need DIO, AO, and AI.  From the NI standpoint, this likely means you'll want PXI or cRIO.  I'd have to know a great deal more to really help you focus in any direction.  But, I wouldn't want to recommend ANY purchases without understanding what is motivating the desire to change.  I prefer point you in the most cost efficient path.  It doesn't sound like you know enough about the system to currently be making decisions about what hardware does, or doesn't, make sense in the system.  Until you know that and have a reason you want to move forward, it's going to be very difficult to provide meaningful help.

[dsabene]

---

@BoKnows wrote:

Adding on to what Ben has already stated, I'm a bit confused as to what it is you're seeking to "solve" with all of this.

If you're currently using PXI, it's likely you're using LabVIEW to interface with the PXI.  If you want to use the same code, it's likely you'd have to remain with the PXI.  Otherwise, you'd be changing your code to handle the hardware change.  If you already have the PXI system, you'd have to spend money to replace that hardware with something else.  Are you looking to duplicate the test system and are concerned about the cost of the system?  If not, I can't see how this would provide a cost benefit.  I can only see form factors.

It sounds like you're going to need hardware to talk to both CAN and LIN.  You also potentially need DIO, AO, and AI.  From the NI standpoint, this likely means you'll want PXI or cRIO.  I'd have to know a great deal more to really help you focus in any direction.  But, I wouldn't want to recommend ANY purchases without understanding what is motivating the desire to change.  I prefer point you in the most cost efficient path.  It doesn't sound like you know enough about the system to currently be making decisions about what hardware does, or doesn't, make sense in the system.  Until you know that and have a reason you want to move forward, it's going to be very difficult to provide meaningful help.

---

Bo,

You are correct that I am not absolutely sure how the current system works. I am doing this project from the direction of my boss. He believes that by the use of this device that I am developing that I can use it at any test station within the company. Imagine 3 different test setups for 3 different parts. The complexity of this device is intense. What we are hopeing to acheive is to be able to take one device to all 3 stations and test each part no matter what type of part it is. That is about as vague of the information that I have been given thus i have unfortunately been vague with this post because I am having trouble pieceing much of this together. Hopefully, the conversation I intend to have tomorrow with one of our test engineers will allow me to gain a better perspective.

Dennis

Edit: Yes the current systems do use LabVIEW with the PXI systems. This is where my biggest questions lie, I need to eliminate the PXI system at the same time as being able to handle all of the functionality it provides and the flexibility that my boss is looking for.