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.