Rewrite c code program with labview

[colorizedice]

Hi, Friends:

Presently, there is a laser controlling program written by C language in our lab, and I'm planning to rewrite that program by Labview, for I can control the hardware more conveniently. 

I'm not quite familiar to the C code, and I just know there are many dll files, which are invoked by the main GUI. So, in my hand, I have hardware, dll files, and labivew. Is there a way to realize my purpose?

Thank you very much for any advice.

[GerdW]

Hi ice,

your question is very similar to this one - and the same answers apply…

[colorizedice]

Thanks for quick response.

[Bob_Schor]

You have a wonderful opportunity which I've done, myself, when faced with "really old code that may not quite work the way you need it to work" -- Start Over!

• Step 1 -- Write documentation first. 
  • Describe what you have to work with (you mentioned Lasers, so describe them and their controls, as well as any sensors).
  • Describe in broad strokes what you want to do.  Don't sweat the details, don't worry about how to accomplish any task.  It is enough to say "Turn laser on, adjust position, then pulse laser with these parameters ...".
  • Include in your documentation descriptions of the data you hope to collect.  Are you recording the Protocol "as you do it"?  Are you taking measurements?  Consider the types of data (analog, digital, Voltage, Temperature, etc.) and timing considerations.  Also think about how the data will be stored and analyzed.
  • Give some thought to what you want as a Front Panel.  I recommend keeping it "lean and mean" -- too many Bells and Whistles can complicate coding and debugging.  
• Try to come up with a Structure/Framework in which to fit your Project.  I suspect something like a State Machine or a Queued Message Handler (there are examples of both floating around, including shipping with LabVIEW) might be a place to start.
• Before you begin coding, get yourself acquainted with a Version Control System (Subversion, Git, others) and use it.  You should never have "Main, v1.2a", just Main.
• Manage your Project using the LabVIEW Project environment.
• As you start to code, be sure that every VI has both Documentation and a recognizable Icon.
• Try to keep all of your Block Diagrams small enough to fit on a single (non-humongous) screen.  One way to do this is to realize that a sub-VI occupies only 32 x 32 pixels (and the Error Line Runs Through It).
• Use the 4-2-2-4 Connector Pane on all your VIs, with the Error Line running through it.  [If you need more than 12 connections, you should probably "simplify"].
• Find a partner, preferably someone who knows LabVIEW, and hold frequent discussions.  Present your ideas and your work -- you'll uncover many bugs, yourself, doing this.  [I've heard this described as the Rubber Ducky Debugging Technique].
• Test code.  Write little simulators.  Do things in small pieces, then assemble them.

Good luck.  This may sound like a "slow" way of doing this, but you are much more likely to "get it (almost) right the first time", and save yourself endless frustration trying to debug "the kitchen sink" and spending weeks on code that barely works ...

Bob Schor

[colorizedice]

Thanks Bob.

Actually, I already finished the steps you mentioned; however, when I got down to details, such as invoke dll file, I met some trouble. Because I have no original manual or source code of my device, I am not sure which function should be used for carrying on some operations.

Thanks.

[altenbach]

How does the laser connect to the control system (serial port? Digital or analog triggers? GPIB? Ethernet? Commercial controller? Some home build contraption?)

What does the program do? (Just fire laser and honor safety interlocks? Synchronize with other IO? Coordinate many things in time and space as e.g. in a laser etch system? )

Chances are that these dlls are some vendor supplied "drivers". See if they provide LabVIEW equivalents.