joshxdr

I apologize if my question is only tangentially LabVIEW related. I have a machine that is a custom microcircuit wafer prober that due to a strange history has unfinished LabVIEW software. My new management wants to replace the existing software with a fully functional version written with python. I am hunting for a contractor that can develop software similar to (but simpler than) Cascade ControlCenter on a machine that has a set of Newport lead screws and controllers. The machine physically lives in Eastern PA, within driving distance of NY or Philly. A lot of debug will have to be done on site with the machine. Do you guys know how I would start hunting for a good contractor to do this job? Any recommendations?

I am using version 7.0 for SPARC. There is no graphical compare available for this version I am aware of...

I believe you can load lv5.1 code with lv7.0, and then open lv7.0 with lv7.1. I have done something similar before, it did not seem to impact the functionality, your experience may vary of course. My experience may not be typical, but I have seen old systems that were built by a new grad as his first ever software project, and a revolving door of semi-skilled engineers performs copy/paste/bandaid edits until the code is an unreadable unreliabile mess. Then years pass and everyone assumes that the old system is perfect, like scripture handed down from the ancients. If this is the case, do the right thing, put that monster out of its misery and build a real system. You may find that magically your quality, throughput, and development cycle times magically improve and you get to be the hero.

I see what you mean in terms of converting back and forth between graphical and text formats. It is almost impossible. Also, the sequence of elements in the text file would be somewhat arbitrary, and you would be jumping around a lot in the file(s) to figure out how something actually worked, while in graphical form it would all be in one page. The analogy between LV and circuity schematics is maybe not as strong as I had assumed. A LV vi will wait forever until the input ports have valid data and then execute. A circuit block will execute its function when it gets a clock edge, it doesn't wait for valid data. A digital circuit goes from register to register with some logic in between each register. This is really more of a line-by-line execution than a dataflow execution, so it is not really the same thing.

My interest in text representation would be version control. At my company, the general procedure for software qualification is that old versions are compared to new versions with text compare by a non-technical QA guy, and I explain all of the changes. This actually works out very well, since it forces me to have formal check of all changes. This is not possible with my version of LabVIEW. Other than that the graphical representation is fine for the kind of software I develop. As a general comment, I know a lot of designers that started out designing circuits with schematics, but switched to a HDL like Verilog. From what I can tell, for very large complicated digital designs, the graphical representation gets too unwieldy. For circuits like memories and analog circuits, schematics are still used, so there is a place for both kinds of representation. If a text version of G were available, I imagine very large, complicated, multi-developer projects would be possible. I think there is an opportunity for a G competitor to arise with a dataflow-based language with both graphical and text-based representation. Dataflow programming has some advantages for creating code for multiprocessor systems, so maybe this is a possibility...?

Electrical circuit design can use either schematic or HDL. They are equivalent representations of the same thing. The designer can choose the best solution. Why does G have to be graphical only?

Fixed typo: I have LV7.0 on Solaris and LV2010 on Linux, and I used them both to check out what I can do to lock files. For LV7.0, there is a "deny access" input on file open, but it does not do anything, perhaps it is only functional for windows. For LV2010 there is a separate "deny access" vi, and it does work. Unfortunately I need this solution to work on the Solaris system, and LV7.0 does not have a dedicated "deny access" vi. One thing that worked for LV7.0 was to use the "access rights" vi, which modifies the unix permissions on the file. Setting permissions to "0" prevents the other process from accessing it. This is not a perfect solution, since I need to "open" and then "read" before I lock the file. But it is better than nothing.

I decided to cut my losses and live with imperfect counting for now. If I miss one or two touchdown counts out of a thousand I don't really care. It turned out to be somewhat painful to replace the contents of a file. I had to find the length of the new string, manually move the EOF byte to the new string length, then write the new data from the start of the file.

I have LV7.0 on Solaris and LV2010 on Linux, and I used them both to check out what I can do to lock files. For LV7.0, there is a "deny access" input on file open, but it does not do anything, perhaps it is only functional for windows. For LV7.0 there is a separate "deny access" vi, and it does work. Unfortunately I need this solution to work on the Solaris system, and LV7.0 does not have a dedicated "deny access" vi. One thing that worked for LV7.0 was to use the "access rights" vi, which modifies the unix permissions on the file. Setting permissions to "0" prevents the other process from accessing it. This is not a perfect solution, since I need to "open" and then "read" before I lock the file. But it is better than nothing.

I did a little research and it appears that this is not as simple as I thought. Serializing access to a shared resource seems to be a potential trouble spot for any kind of software. The only way to guarantee that a race condition does not occur is for process A to lock the file, and for process B to wait for the lock to be released. By accident I have created a poor-man's file lock by deleting the original file after reading, although there is still a narrow window where a race condition can still occur. Does anyone know if there is a "file lock" vi and a "wait for lock" vi? Can I do this from the command line in Unix using the system exec vi? Ok, here is an idea I got from the internet: Check for the existence of sharedfile.lock If sharedfile.lock exists, wait 10ms, go back to step 1 Create sharedfile.lock Open sharedfile.txt Overwrite sharedfile.txt with new value Delete sharedfile.lock Does this sound like it would work?

I recall trying to open for write, but I had a problems. Either I had a permissions issue (we are on a Unix system) or I only had an append option and not a replace option. I will recheck. From the Unix command line, I can use utilities like sed or perl to perform in-place modifications to files. I assume these utilities are immune to contention issues, or are they....? I assume the problem where multiple programs read and write the same file is a common one in the software world. I would like to use an industry standard type of solution rather than a kludge. Network variables are a LabVIEW-specific kind of solution, I would be more comfortable with one that is more standard.

I am using LV7.0 on SPARC Solaris. I have two executables that are reading and writing the same file. The file is a simple record of how many times a probecard has touched down on a wafer. I was not able to find a vi that can edit a file in place, so when the file needs to be edited, I delete the file and write a new one. This causes problems when I am running the program on two machines at the same time. Once in a while, one of the machines will try to access the file during the brief period that the file is already deleted. I suppose I could put the error into a case structure and retry until the file is present again. Is there a vi that I am missing that can do in-place edits and removes this collision problem?

I guess this is why my wife keeps telling me I need to network more. If I don't get my name out there, the "people behind the locked door" will never know who I am, no matter how well I do my job.

Actually the opportunities I am interested in are internal to my company. I have made big improvements to automation and processes in my current job, so in the future I will have time to get involved in other projects in addition to my current job. The security clearance would help with finding extra projects, but not with my current job. My employer currently pays for education expense if it has long-term benefit at the company, even if it is irrelevant to your current job. For example, my technician is studying to be an engineer and the company pays. I wonder if security clearance could be looked at in the same way?

I work in a small but important corner of the company that does not require security clearance. I assume there would be more options available to me if I obtain clearance, exactly what those opportunities are is hard to say since they are secret. I have been a very good performer so far, perhaps I can request it as a perk even if my current job does not require it.

I am currently working for a division of a military electronics company that makes both digital and RF/Microwave parts. I currently have a CLD in LabVIEW and lots of experience in digital (memory and logic) and DC analog (power management) test. I am looking to improve my pay and job security while staying with my current employer. I have been thinking about pursuing extra projects to learn one or more of the following: 1) Security clearance 2) Experience with PXI 3) RF/Microwave test experience 4) TestStand 5) Text programming experience like LabWindows CVI 6) Rest on my laurels, take long lunches at Chili's I would be interested in comments as to which one would be best in terms of increasing my value in the military electronics world.

Would it be possible to build your vi into a DLL and make your python code talk to the DLL? Do you have an application builder license?

Thanks for your reply. Unfortunately local storage will not work in my case. And these old Sun stations can't read network folders using smb or zfs, only nfs. I am stuck using another 1998 vintage machine as a file server. At least I can use the linux box for backup and archiving.

I have posted this question on the NI boards, but the only result was the sound of crickets, so I thought I would try here. I am using LabVIEW 7.0 on Sparc Solaris 2.6. I am using NFS to serve folders from a RHEL5 linux server. These folders contain my LabVIEW code, and I am mounting them on my Sparc Solaris workstation. When I open the LabVIEW file browser, some folders and files (but not all) appear to be missing. Here is a link to a discussion on the NI boards where someone had the same problem, but no solution was found: LINK. LabVIEW will open the files no problem if I type in the complete path. For example, when I navigate to directory A, there should be SubdirA and SubdirB, but SubdirB does not show up in the file browser. Yet, if I just type SubdirB in the text box, I can navigate to this directory no problem. Using my terminal, I can view these folders without issue. When I use the file browser on nedit, hotjava, tedit, image viewer, etc. I do not have this problem. It is only the LabVIEW file browser that has the problem. I know the obvious answer is to get a more modern version of LabVIEW, unfortunately I am locked into using legacy hardware to be compatible with legacy test equipment. The latest version of LabVIEW my Ultra 5 can run is 7.0. Is there a change I could make to the NFS settings? To the LabVIEW options? Should I try using OpenSolaris instead of RHEL5?

I am making a simple control API for a piece of equipment that has a GPIB port. I am trying to decide to use VISA or GPIB. My understanding is the only advantage to VISA is that you don't need to rewrite your code if you use the same API for serial or GPIB. Is there any other benefit to using VISA? I will never use serial communication for this project.

I used system exec to query environment variables. Worked like a champ!

I am using LV7.0 on an old Solaris machine. I want certain debugging controls to be automatically hidden when the "operator" user runs the vi. It doesn't have to be super-secure, it is just a question of making the interface cleaner and simpler for the operator. Can you grab environment variables and use those? For example, in the .bashrc script I could make a variable called USER and set it to operator. Of course if would be even cooler if I could use shell commands like "id" to get the user. Is this possible in LV7.0?

Can't you just take data from your files, and put them into a chart? Since you are just storing numbers, pure binary would probably work ok. If you want to add parameters and meta-data, there is a custom NI data format (TDS??) this is basically XML with embedded binary that is quite nice, but not compatible with any non-LabVIEW software or tools. How is Excel working for you? Why do you want to use a different format? Am I totally missing the point of your question?

I was used to bringing up the font editor and color palette with the right click on windows, so when this didn't do anything under Solaris I thought there was only one font and one color, black. I figured out that double-left-click will bring up the color palette and font selector just like on windows, so problem solved for now.

I have LV7.0 on Solaris 2.6 (yes, quite old), and I need a better icon editor than what is provided with LV. I noticed a couple of icon editors in the "approved code" section but they are for LV9. Any suggestions?