09-10-2013 11:25 AM
Hello,
What I am trying to accomplish is take the output from my drop down list (Spring Name, K1, K2, K3, Open Load, Seat Load) and arrange them in a list to then populate on the spreadsheet that the other chunk of code writes too. It needs to be after user data and before spring on the spreadsheet writing portion of the code.
There will have to be an additional column header for the larger output, I know.
I was partially successful previously in wiring the spring info from drawing output to the input between the user info and spring, but when i opened the spreadsheet the cells were all populated with somthing like 'long binary'
hopefully what I am asking is clear, if not let me know
Thank you
09-10-2013 02:07 PM
09-11-2013 09:23 AM
You are correct, I intended to say database and not spreadsheet. Is it in fact writing to a database
I would like to select an option from the drop down menu, (the selection populates other fields) and when the VI writes to the database have it include the populated fields in a column. In theVI i have the 2 pieces of code seperate. the 5 fields that get populated from the drop down VI I would like included in 1 column on the database
hope that helps clarify
thank you
09-12-2013 09:28 AM
I suggest using a State Machine template for your design. Are you familiar with State Machines in LabVIEW?
You may consider using an event structure to detect a button being pressed, rather than polling it every 100 ms as well.
As a note, most databases are row-oriented structures; their insert functions will insert data as an entirely new row.
When you say you want to write the data to a column in the database, do you really need to write to a single column, or will writing the data into a new row be acceptable?
09-13-2013 10:01 AM
Here is a copy of some sample data written to the database. It titles columns and writes to them.
I would like it to be columns since everything else i have does the same.
I am not too familiar with database stuff so it could very well be row oriented and i wouldnt know it specifically.
so if it inserts each term in a new row that would be alright. i think my wording is incorrect when i say columns
it is a microsoft access database
I do not know about slate machine or event structures.
09-16-2013 04:04 PM
The data that you have displayed in the screenshot in the database is row-oriented. This means that the data is being input horizontally, spanning multiple columns. It appears that this is working fine.
Your initial post said all you were seeing was "long binary" in the database. Have you tried writing other data types besides your cluster? What happens if you just write one integer, or a string?
As a side note,
I highly recommend using the example finder that is built in to LabVIEW so you can become more familiar with the program as well as common design patterns. It is located in Help >> Example Finder.
09-17-2013 11:06 AM
Thanks and yes I do try and go through the examples as best I can and sample/learn from them.
I added an image of the database where it lists the long binary data.
The way it lists is in the column which is why i made my assumption, but I can understand why it is row oriented.
My goal is still the same, to get my populated drop down lists to write to the database when running the program. If there is an example for that please let me know.
surely someone else has done this before?
09-17-2013 12:27 PM
You can find an example of inserting into a database in the example finder.
Example Finder >> Toolkits and Modules >> Database Connectivity >> Database Insert
I suggest starting here and adding your code on piece at a time, testing in between, to make sure that it is still performing the way you expect.
From your last screenshot, it looks like your table is not being created properly. The Long Binary Data is the type that Access has assigned to that column, meaning that whatever data type that you fed it cannot be interpreted. I suggest creating a new table with the predefined column types that you are expecting. You may need to typecast your values (on the LabVIEW end, before inserting them) into strings to guarantee that what you are inserting is simply an ASCII string.