Jump to content

Benoit

Members
  • Posts

    158
  • Joined

  • Last visited

  • Days Won

    16

Posts posted by Benoit

  1. 2 minutes ago, forest74 said:

    Howdy,

    Thanks for posting the code. It is very helpful. I am interested in trying to get the file operations working. Do you have any suggestions?

    Thanks,

    Mike

    Hello Mike, It's been a while I created this library. I was never a big fan of the file function. So I never used it. I am afraid you will have to do some coding and research.

    Benoit

  2. Hi,

    I can't understand how 3D graph are working.

    What I am trying to do is to plot multiple point XY with a Z as intensity of the measurement. I was expecting a x,y,z coordinate, but 2D for the Z... I just don't picture how it works.

    I got a half sphere with sensor. I am trying to represent in 3D X,Y the position of the sensors as a flat position ignoring the Z and using the Z for the sensors values.

    Please help.

    Half sphere.png

  3. The sequencer that you use is it TestStand?

    Actually, The design I did give me more advantage than what is offer by NI. so no... I wont design it differently.

    When I want to add a Power supply model/manufacturer into the list, I have to modify only the middle lever of the HAL by adding a case in the list of every function. that case hold the driver from the manufacturer(LabVIEW,.dll or other)

    I can't show you by video right now. Not sure my company will allow me to do that. In the case of your sequencer, I believe that no other software will call your driver... I think that you can remove the VI server call layer. To keep the object in memory, you just need to keep the reference open. a getset can do that or I think if you use TestStand, it is possible to keep reference in memory as well, but I'm not sure. I didn't use TestStand since a while. the cost is too high and development time for the same test is to long compared with my test framework.

    Benoit

  4. The call is done by the following step.

    Init: create a reference on all the function "VI" for that instrument. (keep in a getset)

    Function call: from get set use the reference of the function to send parameter or get parameter of the instrument

    Close: close all the reference from the getset

     

    In the .exe that holds all the Instrument, I have every instrument function in separate re-entrant VI.

    The physical init to the instrument and physical close instrument in done by the executable not by the caller.

    This allow the caller to have the status of the instrument initialization at every function call since I keep the error in another getset. The time to initialize the instrument is done by this executable, not by the caller.

    This architecture allow me to have an auto-recovery of any communication failure. This allow me as well to have only one prototype for calling any instrument that has the same function. Per example, the power supply 0,1,2,3,4,5,6... all have enable output function. by setting the PSU# at the function call, I can do whatever I want on whatever instrument...

     

    I do have 4 layer on my HAL, but the two other wont be necessary for you I think. The two other layer are

    Communication layer. ( a power supply can have 3 different output physically. I can access them virtually at the same time by different VI server call without sending 3 command at the same time on the serial port. (I made a queue at this level)

    Position Layer. The position layer is that I have a test framework that allow me to use in batch mode, unit mode or even asynchronous mode testing anything. per example, if I have 16 position on my tester that is used by 16 different .exe, I don't want to program differently the 16 .exe. I just add one layer with a config file that tells what position use what PSU# per example.

    So yes... crazy design, but if you can see what i can do now... FCT, Burn-IN, Programming, Hipot station and much more all with the same GUI. Only the test sequence (.exe) are called depending of the product I want to test. The product is selected by the serial number and a call to the MES system. That allows me to test different product part number and version on the same tester and same GUI. :)

    3 years design for this crazy system.. and now.. I cannot see anyone in the industry doing something better than that. A Product test development that use over 300 measurement point and 20 different instrument with various technology takes me only one week and it's deployed and validated in production.

     

    image.png.513919393fdec143bfd80f5a7a420067.png

    Benoit

  5. For my part, I use VI server call per function per instrument.

    The VI that is dynamically is in another .exe.

    This .exe has all the driver for all the instrument. the instrument selection and availability is done trough a .ini file.

    currently I support 22 different hardware like JTAG, Eload, PSU, Hipot, I2C CAN bus, SPI, Oscilloscope, Switch, DAQ, Ethernet, serial port, etc...

    Each instrument type support multiple manufacturer and model.

    When a call is done by VI server, the capability of the selected instrument is evaluated and report an error if out of range.

    This is generally what I designer here. I decided to stay 100% LabVIEW.

  6. Are you sure it comes from that VI?

    As I understand this VI is called with different function on every call. the one that will be called the most will be "Log Data".

    So I strongly suggest to create a unit test with your VI called multiple time with this function to validate if the leak comes from there. But I am pretty sure not...

    What the rest of you project is doing? Other question... what is the file size generated?

    Benoit

×
×
  • Create New...

Important Information

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