LogMAN

I just figgured you must be able to read English in order to understand my original post in the first place! LOL, and I go through the trouble translating everything... Hahaha thanks, you made my day

Let me translate this properly: GERMAN: (translation below) teeemzeh, auch wenn dies ein englisches Forum ist, antworte ich ausnahmnsweise auf deutsch: Nach meinen Informationen hat Keyence keine fertigen LabVIEW-Treiber, sondern verwendet allgemeinere Protokolle, meistens ASCII-Basierend. Der Support von Keyence ist immer der richtige Ansprechpartner, also einfach anrufen und nachfragen. Die Kontaktdaten sind hier zu finden: Keyence Support. Übrigens sind die Vertriebler häufig die besten Techniker und helfen auch bei der Inbetriebnahme und fast allen Fragen. Ich habe damals über den Support die entsprechenden Protokolldateien, sowie einen technischen Ansprechpartner erhalten und mit dem Vertriebstechniker die Inbetriebnahme durchgeführt. Der Marking Builder ist zudem zwansweise erforderlich, um den Laser zu parametrieren! Ansonsten verwendest du das DIO-Interface (Programmwahl, Sicherheitskreis, etc...) und sendest einfache Strings (Datenblock & Daten)... Wenn ich mich richtig erinnere hatte der Laser einen RS232-Port, der in LabVIEW sehr einfach anzusprechen ist. Leider habe ich keine VIs, weil meine Lösung nicht in LabVIEW umgesetzt wurde. Ich empfehle zukünftig für Anfragen auf deutsch lieber bei ni.com/community/d, oder labviewforum.de anzufragen. ENGLISH: teeemzeh, even though this is an English forum, I'll once answer in German: Keyence does not provide ready-to-use LabVIEW driver as far as my information go, instead they make use of more generic protocols, mainly ASCII based. Contacting the Keyence support is the best option you have, so just call them. Contact details can be found here: Keyence Support. The sales guys are most likely the best technicians you could ask for and they will guide you through commissioning and almost any question. Back then I received the protocol files from the support as well as contact to a technician and I did the commissioning together with the sales technician. By the way, the Marking Builder is required to parametrize the Laser! For anything else you use the DIO interface (program selection, safety circuit, etc... ) or send plain Strings (Data block & Data)... If I remember correctly, the Laser had a RS232 port which is very easy to use in LabVIEW. Unfortunately I don't have any VIs, since my solution was not implemented in LabVIEW. I suggest writing German question on ni.com/community/d, or labviewforum.de in the future.

Reading all the posts, it seems that many people used multiple event structures on one block diagram at some point in their life. In fact I did so too, however this has either been because of bad design decisions (use Sub-VIs instead!) or because I didn't know better (wait what? ). It would be no problem for me to limit the number of event structures to one, or rather I would like to see one event registered only once in the same VI (maybe thats already limited in a more recent version than LV2011?). There have been very strange behavior in my VIs ages ago (4-5 years) as I tried to catch the same event on a prallel event structure (never got it working properly) In my optionion parallel event structures are like global variables, you could use them and it might seem easier, but the maintainability gets worse and worse the more you use them and you must be very strict to the limitations of their usage. So don't use them at all! The only reason I could accept so far is the one of Darin (because they are strictly seperated by their scope): However even this should have and has been solved in sub-VIs.

I can only guess based on the help, since I generally use pure SQL syntax... The update statement will try to update all columns in your table which is impossible as you need a primary key (a column that is the unique identifier). This would be 'speedo_ok' in your example I guess. You could now either update element-by-element using the condition input WHILE speedo_ok={speedometer values.select} where you have to replace {speedometer values.select} with the actual value of the particular element. The second option is to present a new primary key to your table that is set to auto-increment; and always define the column names for your cluster whenever you use the cluster to insert / update / etc... The update statement with all cluster elements makes no sense as far as I understand, as this would cause all rows to carry the exact same information for each column. As I mentioned before, you need a primary key that is unique. Try to update a certain element of your cluster using the condition I mentioned before. Maybe someone else could give an actual example how to solve this based on the DB VIs? No problem, I had to learn all that stuff too A good source for SQL has always been http://www.w3schools.com/sql/ or MSDN of course for MSSQL. Just for my own satisfaction , but this would be the SQL syntax (I did not test it, but it should work): You have to replace all elements in {} by their representatives in the cluster. Green would be valid, red is what you try to do (I still assume speedo_ok is your primary key): UPDATE speedometer SET speed={max speed}, frequency={speedo max freq}, amplitude={speedo amplitude}, pulse_rev_n={speedo pulse/rev}, ratio={speedo ratio}, pulse_type={pulse type} WHERE speedo_ok={select}; UPDATE speedometer SET speedo_ok={select}, speed={max speed}, frequency={speedo max freq}, amplitude={speedo amplitude}, pulse_rev_n={speedo pulse/rev}, ratio={speedo ratio}, pulse_type={pulse type}; I hope that helps.

The condition terminal is well described in the help: EDIT: Should describe anyways: Let's say your table consists of a pair of ID + name ( 0 | bill, 1 | john, 2 | pa_l, etc..) now you want to update the name of the row in which the ID is 2 ('pa_l' should be 'paul'), your condition would be 'WHERE ID = 2'. Your current data is of variant type. What data are you trying to send: cluster, string, numeric, ...? -> I guess you get the error because the data terminal is not correctly wired. The table input specifies the table name and if your table has for example three columns (id, owner, description) and you only want to update the description, you should set the first element of the columns terminal to 'description'. (And only provide the new value of description to the data terminal!) Could you provide some more information about your actual data type & table layout?

This is very interesting. Do you know any particular page we could look up for that kind of stuff (like a comparison between MS-SQL vs. ODBC vs. ...)? My main source is MSDN as well as various pages I could find over Google.

Update: My computer finally decided to take a rest, so I decided to restart LabVIEW and try that a third time. The environment does run just fine without any disturbing disk activity. Am I seeing stuff ? ? -> Restart again, as third fourth time's the charm, now waiting for 30min... New VI as before, constructor and... nothing! So obviously the MsMpEng.exe did not relate to the issue at hand and was randomly scanning my computer twice just as I placed the constructor. Thanks Bill!

Let me share my experience based on your example: As soon as I load the constructor, my system shows heavy disk operations. So I close LV (eventually killed the process)... Restart the system in order to try again... Wait for 15min, until no process does anything anymore, take a look into the resources monitor -> everything is fine. Now again starting LV -> create new VI -> insert the constructor, wait approx. 5s... System overflowing with disk activity (100%). The load is caused by MsMpEng.exe which is part of Microsoft Security Essentials. For some reason it will start scanning the entire computer!? (The highest load is given to the MFT). Of course LabVIEW is now very slow as many other programs that rely on disk activity. All caused just by putting the SHA256Managed constructor in a blank VI! Tested in LabVIEW 2013 (32bit) on Windows 7 (64bit) Maybe somebody else can confirm this behavior? Hint: The constructor is located at: mscorlib->System.Security.Cryptography->SHA256Managed

Did you try to use a stored procedure instead? If this would return any records, the next step is to analyze the query for issues or inform NI about a possible bug. Also could you post the SQL query or an example that fails?

I'm unsure.. There have been some issue with the layers but I can't remember where I read about it. Sometimes the background appears black (if you try to copy it from MSPaint that is). I generally use Paint.NET or Gimp to save my PNG files and they work fine. Maybe the file has some strange parameters? Try saving a copy with default options from one of the tools I mentioned. Now that I read your post again: I assumed you are talking about a picture where some areas are empty (100% transparent or more specifically non-existing!). I have never used an picture with parial transparency on a control and my guess is that it might not be possible. I wonder if anybody has experience on that.

I haven't looked into it, but the description says I assume it is capable of renaming VIs without loosing the revision history: http://sine.ni.com/nips/cds/view/p/lang/de/nid/211524

I think the most annoying issue is that you can't actually rename a folder in the files tab of the project (this could be so easy!). I generally go to the files tab, select everything in the current folder, right click -> Move on disk..., create a new folder at the desired destination and press save. As this entirely depends on LabVIEW, there is no relinking done (well there is, but no search dialog). However the old and now empty folder (including the entire filder hierarchy) remains and cannot be removed because LabVIEW keeps locking it (I think it is the search location for the next save/load dialog).

Which file types did you use? PNG files do generally work for me, unless you copy them from any other program (like paint). Use the "Import picture from*" function from the right-click menu instead.

Your example should create a table with 2 columns (1x Numeric & 1x Text). The table name is '123' and will have 4 rows ( 1|abcd, 12|abc, 123|ab, 1234|a ). I'm not sure what you are trying to archive with it. Anyways, here is my example (did not test, but it should work if you open the database properly): If I'm correct, the database should get a new table 'fancy_table' with three columns 'column_1', 'column_2' and 'column_3'. The table should also contain a single row with data ( 'first column' | 'second column' | 'third column' ). The maximum text length for each column is 50.

So the error vanished if the string length is the same. You should know, that databases have fixed length information on text columns, therefore preventing more input data to be written to it. (there are some exceptions, but I don't know about any in Access) you should manually set the size for each column in the table, there is a function to do that: 'DB Tools Create Table.vi'. If you create a table with the expected number of rows and set the text length to 250 for example, the field should be big enough to contain any possible data the user could input. Also that way you can specify the column names and use them for the insert function. Be careful not to make the field to big, as each entry will use up the entire length (unused parts are filled up with 00 afaik)!

The help says: 'creates a table if a table does not exists...' But I think the problem is based on that parameter anyways: According to the help, the size of a column is decided by the size of the input data, if the table is created by that function ('create table?' is set to TRUE). Assuming that your input data does have different string-length, the columns which are created in the first iteration could be to small for the next one. Thus the function tries an 'ALTER TABLE' which does not work for some reason. If that is true, try to pass a longer string to the first iteration. Also the method Phillip Brooks described is a good practice to prevent changes to the table after it has been created.

It is hard to help you if there is little to work with. The error is unknown to me, but it says that your database is read-only. So if you look into your UDL file, you can set it to read+write access (in the 'advanced' tab? - sorry, I've got a German system). Also shared access to Microsoft Access Databases is not possible afaik, so close the database in MSAccess before using it in LabVIEW. If the error does not go away, maybe you can post some pictures of your source code, the UDL configuration and database.

LabVIEW 2013 is quite new and to me it is relatively normal for a new version to present annoying problems until the first SP release and .f# bug fixes. I had to switch to LV2013 from LV2011 for a single project with about 2k VIs, since the project did crash on the old version due to some architectural issues that could not be solved in time. However on LV2013 it worked quite well and even better when it comes to classes and property nodes as well as large cluster hierarchies (still some lag, but much less than before). So far I have found only one critical bug which has been solved recently: http://lavag.org/topic/17137-error-generating-preview-in-installer-properties/ Whether or not the new version is better or worse for you depends on your project size, architecture, used addons, etc... Anyways I wish NI would spend more time on fixing bugs and increasing performance of the IDE rather than implementing more and more possibly unstable features. Whenever a new version is released, the methods we do to validate the stability and usability of that version is very time consuming and more and more often leads to the choice to not update to the newer version (used 8.6.1 till 2011, and 2011 since than - 2013 is an exception after hours and hours of discussion). The main reasons to not update are bugs which cause our VIs to stop working or systems to crash after several hours. My experience is, that in almost every case the IDE is unstable because the sources are not very well designed (see discussions regarding code complexity & dependency trees). So I think as NI should work on stability and performance, we have to work on our own sources to solve bugs and decrease code complexity. Due to new features in the IDE, the code complexity will increase, sometimes without us wanting to, because we do not always understand the behaviour and/or purpose of some components.

The issue has been taken care of in the related post and a fixed version of the offending VI is provided too: http://lavag.org/topic/17137-error-generating-preview-in-installer-properties/#entry106670 A future patch (currently f2) should include the fix.

JeffP I've tested your file and it works just great! I can now finally see my precious preview and build the installer! Thanks

Reading someone else's memory is limited by the memory protection system. Here is a link to a MSDN site that briefly describes the topic: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366785%28v=vs.85%29.aspx Whenever you try to copy memory that hasn't been allocated, there is a chance to get an access violation exception. Whether an exception occurs or not depends on the data that is accessed. For example: Assume you've allocated an array of 512bytes and one of 256bytes within your DLL. Memory is allocated in contiguous blocks, therefore the block would have a size of 768bytes. Now you accidentally read 712 instead of 512bytes of the first array, but no error occurs, because the memory is within the same block. The result would just be an array of the 512bytes of the first and 200bytes of the second array. Next you try to read 1024bytes and get an access violation, because the number of bytes overlaps the number of allocated bytes. This is just a stupid example, since there is much more to it, but this should cover the basics ( and I can't explain it much better ). Long story short: Do never access memory, that is not allocated properly! As you're calling a DLL, the allocated memory is in the same space as the LabVIEW IDE / Runtime, therefore you are trying to access data of some LabVIEW internal memory blocks, which are most likely protected. I also assume that LabVIEW does force some memory protection over all DLLs that are called in its scope. The result is what drjdpowell just posted: Yes, Microsoft is a bitch when it comes to protecting precious data. The memory management standards are now insane compared to XP. In most cases if you set the error checking options to maximum, the LabVIEW IDE will show violation errors if memory is incorrectly accessed. That might help you to pinpoint the issue. Of course there is also always a chance to crash LabVIEW because you incorrectly accessed memory... Wow, I've just wrote an article to questions that could be answered with two 'yes'

I can't give you any VI, as I have currently no system with the database connectivity toolkit installed, however I would build the query manually and supply it to the 'Execute Query' VI (I don't even know how all the other VIs work ). Your query should be: notice, that: 1) 'Prueba' is the table name 2) 'date' is the column name 3) %s should be replaced with the date you want to supply (use the 'Format Into String' VI) Your value must not contain a single quote as part of the value and ID must be set as auto-increment. I'm not sure if the value must be put into single quotes ( '%s' ) or double quotes ( "%s" ) ... Hope that helps.

Great, thanks! I'll try as soon as I'm back in the office the week after next week. You'll get an update then.

So I'm on the dark side now? http://lavag.org/topic/16925-controls-change-positions-on-runtime-system/?p=103828 neil, I am your father... maybe...

Thanks JeffP for the update. I've installed the patch, but unfortunately, this does not solve the issue. I still get <Error generating preview> in the installer dialog.