Jump to content
dterry

"Propagating Calibration Changes" or "Difference Based Configurations"

Recommended Posts

1 hour ago, dterry said:

ShaunR,

It seems like the database you sent is encrypted.  Is there a password?  Right now, I get errors because the file path ("TM.3db-> 12345" + AppDir)  seems to resolve to <Not a Path>.  I replaced it with a hardcoded path, and got the "Enter Password" dialog.  Taking a SWAG, I entered "12345", but it threw error 26 [file is encrypted or is not a database].  I found that the password dialog was being bypassed (see below), but it worked fine once I rewired it.

2017-02-15_1129.png

 

From what I can tell, the schema you put together looks some like my E-R diagram above.  It helped to be able to see it somewhat implemented, and I think I may end up going this route, and dealing with the consequences (enforcing names/types/values, complex queries, application side logic, etc.).  

 

Thanks a ton for your help with this!  It has been very enlightening and helpful in narrowing my focus for configuration management!

 

It says on the diagram password is "12345" although I'm so familiar with the syntax I didn't really give much thought that it wasn't obvious for those that haven't seen the "Speed Example". If you want to see it in other packages then just make a backup (there's a button for it in the toolbar). The backup will be unencrypted. It still has to go through formal testing for inclusion so thanks for the debug (re: path wire). Not sure why you got "not-a-path" since it is supposed to return the filename appended to either the project directory or the directory from which the top level VI exists in. I expect that will disappear when it is included in the main package but I will error guess to see if I can smell the reason and make it more robust.

With regards to types. SQLite is [almost] typeless - It is one of the reasons I love SQLite . It uses what are called affinities which, for the most part, affect how data is stored rather than imposing type constraints. I use this to remove the strict typing in LabVIEW (you'll notice everything is a string). If you move to another DB then you will of course have to consider the types and your code will become more complex as you convert backwards and forwards for the specific types.  You will also notice that each parameter has a "type" field, which is nothing more than a text label so that when required in LabVIEW, the strict typing can be reintroduced for the things that matter, if desired. (the VI I used to "guess" your types from the INI files needs some more work ;) ). That isn't required for this configuration example (everything's a string...lol), But it is based on a real configuration editor I have written many times over for different people.

You have a number of choices from this point on for "Steps". You could make another table just like the "parameters/Limits" or you could just use labels (groups). The problem with the former is that it is not very generic and you usually run into problems further down the line with instruments "in use" when they are used for multiple test steps in parallel. The labels approach enables you to just use a filter on the parameters (works for both limits and configuration) but I can see good arguments for either. You will note that the schema is hinged on Instrument configuration and steps don't really factor into that very much - just like the tests. So the schema isn't hierarchical from Test>Steps>Parameters as you show in you second ER diagram.

Calculations are anyone's' guess. I don't know what they are for or what they do. Off the top of my head, I would probably consider them just another parameter with a "calc" label or group.

Share this post


Link to post
Share on other sites

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.


  • Similar Content

    • By McQuillan
      Hi Everyone,
      I (re)watched James Powell's talk at GDevCon#2 about Application Design Around SQLite. I really like this idea as I have an application with lots of data (from serial devices and software configuration) that's all needed in several areas of the application (and external applications) and his talk was a 'light-bulb' moment where I thought I could have a centralized SQLite database that all the modules could access to select / update data.
      He said the database could be the 'model' in the model-view-controller design pattern because the database is very fast. So you can collect data in one actor and publish it directly to the DB, and have another actor read the data directly from the DB, with a benefit of having another application being able to view the data.
      Link to James' talk: https://www.youtube.com/watch?v=i4_l-UuWtPY&t=1241s)
       
      I created a basic proof of concept which launches N-processes to generate-data (publish to database) and others to act as a UI (read data from database and update configuration settings in the DB (like set-point)). However after launching a couple of processes I ran into  'Database is locked (error 5) ', and I realized 2 things, SQLite databases aren't magically able to have n-concurrent readers/writers , and I'm not using them right...(I hope).
      I've created a schematic (attached) to show what I did in the PoC (that was getting 'Database is locked (error 5)' errors).
      I'm a solo-developer (and SQLite first-timer*) and would really appreciate it if someone could look over the schematic and give me guidance on how it should be done. There's a lot more to the actual application, but I think once I understand the limitations of the DB I'll be able to work with it.
      *I've done SQL training courses.
      In the actual application, the UI and business logic are on two completely separate branches (I only connected them to a single actor for the PoC) 
      Some general questions / thoughts I had:
      Is the SQLite based application design something worth perusing / is it a sensible design choice? Instead of creating lots of tables (when I launch the actors) should I instead make separate databases? - to reduce the number of requests per DB? (I shouldn't think so... but worth asking) When generating data, I'm using UPDATE to change a single row in a table (current value), I'm then reading that single row in other areas of code. (Then if logging is needed, I create a trigger to copy the data to a separate table) Would it be better if I INSERT data and have the other modules read the max RowId for the current value and periodically delete rows? The more clones I had, the slower the UI seemed to update (should have been 10 times/second, but reduced to updating every 3 seconds). I was under the impression that you can do thousands of transactions per second, so I think I'm querying the DB inefficiently. The two main reasons why I like the database approach are:
      External applications will need to 'tap-into' the data, if they could get to it via an SQL query - that would be ideal. Data-logging is a big part of the application. Any advice you can give would be much appreciated.
      Cheers,
      Tom
      (I'm using quite a few reuse libraries so I can't easily share the code, however, if it would be beneficial, I could re-work the PoC to just use 'Core-LabVIEW' and James Powell's SQLite API)

    • By jhoehner
      Hello All,
      First time LAVA poster here with my first question. Why do some LabVIEW programmers insist on wiring the error cluster to the bottom of their VI as opposed to the sides as shown in most NI documentation. Is there any benefit to it? Is it 100% a preference thing? Is there a way to make LabVIEW connect error wires like this automatically?
      I've only seen it in advanced LabVIEW code from experienced programmers and some parts of the Actor Framework.
      Your insight and experience is appreciated! 

    • By the_mitten
      The introduction of parallel, read-only access for DVRs in LabVIEW 2017 adds a great deal of flexibility to using DVRs to monitor values in parallel executions of code. Fo\The downside of this, of course, is the necessity of using the In Place Element (IPE) throughout your code simply to read the value. Having IPEs throughout your code just to read a value both takes up block diagram real estate and also takes more clicks than desirable to insert.
      Similarly, though less frequently, there are times when you only need to update the value within a DVR without actually performing any logic inside of the IPE.  This situation is less frequent, at least for me, as I am usually using arrays or classes with DVRs such that I actually need to modify the existing data rather than simply replacing it.
      A more preferable solution to the above situations would be to have Read/Get and Write/Set VIs for the DVRs to simplify the process of working with them. This way, and IPE on the block diagram would only be needed when you were actually modifying the existing data within the DVR, rather than simply overwriting or returning the current value.
      Thanks to the power of malleable VIs and the type specialization structure that is now officially released in LabVIEW 2018, a better solution is now available. I’ve created two malleable VIs, Read  DVR Value (Parallel) and Write DVR Value that allow you to perform a write and a parallel read on any DVR data type.
       Now, you can use a single VI that you can insert via Quick Drop to read or to write DVR values.  
      Download the attached ZIP file to access the two malleable VIs and example code, and please let me know your thoughts in the comments!
       


      DVR Read and Write VIs 1.0.0.zip
    • By takanoha
      Hi 
      I have a simple program which has only 2 buttons for the user interface. When the user clicks OK I want the program to get into the event structure case called "OK Button". Once it is inside there is a loop which continuously waits for 1 second until "Stop Button" is called from the user. 
      But because once the user presses the "OK Button" the program gets into the event and therefore I can not call the "Stop Button". 
      Is there a way to call the "Stop Button" even if the program is inside the event ?
       
      Thanks

      event_out.vi
    • By neunited
      Dear All, 
      I'm new to this forum and I'm really glad I became a member.
      I am currently in the phase of designing a simple program which can control all the DAQmx channels using a configuration file (.ini) which is capable of change voltage range during mid-simulation. 
      At the moment my .ini file reads as follows: 
      [AO Channel 1] 
      Name = T2
      Physical Channel = cDAQ1Mod1/ao0
      Max Value = 10 
      Min Value = 0 
      [AO Channel 2] 
      Name = T3
      Physical Channel = cDAQ1Mod1/ao1
      Max Value = 10 
      Min Value = 0 
      [AO Channel 1] 
      Name = T2
      Physical Channel = cDAQ1Mod1/ao0
      Max Value = 5 
      Min Value = 0 
      [AO Channel 2] 
      Name = T3
      Physical Channel = cDAQ1Mod1/ao1
      Max Value = 10 
      Min Value = 0 
      My LabVIEW VI for the .ini script  is attached. I'm relatively new to using configuration file functions and I don't really understand where "Get Key Names" section should be wired to. I have placed a constant on it for now which reads the "AO Channel 1" but how can I get it to read all the channels in the .ini file.
      I am welcome to all suggestions here, I just want to make sure that I don't cause any problems to any of the channels and use best practice methods. All constructive criticism welcome!
      Thank you. 
       
       

      Read Configuration (INI) File (1).vi
×
×
  • Create New...

Important Information

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