Tom Bress

Yes, it is a Dwyer Love Temperature Controller, the manual can be found here: http://www.dwyer-inst.com/pdf_files/e_90_bpc.pdf I can communicate with the device using the Dwyer software, which also tells me which parity, stop bits, etc. to use. But when I try the Plasmionique Serial Comm Tester I get the timeout error. I can open a port, but cannot read the coils or holding registers.

Hello, Porter. I'm new to Modbus and I'm trying to use the Plasmionique Master library to communicate with a 2-wire RS485 device over a USB port. Do I need to have a 2-wire USB-to-485 converter, or is there a way in the Plasmionique library to configure the Modbus communication as 2-wire? Background: I'm trying to communicate with a Mellen furnace Love controller. I can communicate with it using the manufacturer's software, but whenever I try to use the Modbus Comm Tester in the Plasmionique library I keep getting timeout error (-1073807339). I'm pretty sure I've got the baud rate, parity, stop bits, and flow control configured correctly. The Open Port function on the Comm Tester seems to work, but whenever I try to read coils or holding registers I get the timeout. Mellen tech support suggests it is because the controller is a 2-wire RS-485 device. I'm using a Tripp-Lite USB-to-485 adaptor cable, their tech support says the cable should support either 2-wire or 4-wire communication. So now I'm wondering if 2-wire/4-wire needs to be configured somehow in the Plasmionique library. Thanks.

I'm trying to get up to speed with OO and I have a question. Here is the scenario: In a string-based state machine I have a long string constant representing my list of states, like a program with one state per line. I have a number of these "programs" in the code based on user input. I'm trying to convert this to an OO approach and am thinking of this string as an object called Program. Let's suppose I have three programs: Program1, Program2 and Shutdown. Here are two approaches I could take: 1. Create a Program class with a string control in the data. Then create three method vis: Write Program1, Write Program2, Write Shutdown. Each of these vis is a static dispatch vi that accepts a Program object and writes the correct program to the string control. The programs would be accessed by a single Read Program method vi in the Program class. If the programs need to be changed in the future you edit the corresponding Write vi. 2. Create a Program class with a string control in the data. Create child classes called Program1, Program2 and Shutdown. Set them to inherit from Program. Create a dynamic dispatch vi in the Program object called Read Program. Override the Read Program vi in the children classes and return the string constants that contain the programs. If the programs need to be changed in the future you edit the Read Program vis. Which is better? I think the second option is more in the spirit of OO programming, but is this the best way to implement it? It seems more complicated.

The book is by Craig Larman. I recommend it too, I'm reading it right now. The nice thing about the book is that he teaches UML and OO design principles hand-in-hand. He uses UML to model the conceptual system (domain model) and the OO software approach (design model). The UML visual serves as the "code", he very rarely shows what the code would actually look like in Java. So you can apply the principles directly to LabVIEW without a text-based language getting in the way. By the way, I love cow-orker. Every time I read "coworker", that's how I pronounce it in my head. QUOTE (neBulus @ Mar 19 2009, 10:11 AM)

I remember seeing a sequel once called "Bambi's Revenge". Couldn't find it on You Tube, though.

QUOTE (ASTDan @ Feb 18 2009, 04:11 PM) I'll be there! I may be late, but I'll be there!

QUOTE (crelf @ Feb 18 2009, 03:39 PM) That's just what I intend to do. Well, maybe I'll fill the void with sleep, LabVIEW and some single-malt scotch! Actually, I don't want to pursue a career in plastics. I've had much more fun with my day job doing LabVIEW-related stuff. Currently I'm playing with the Wiimote vis available on the NI website. We give the senior mechanical engineering students an open-ended project involving accelerometers, this term I'm going to outfit our PCs with Bluetooth dongles and throw some Wiimotes in the mix. It will be interesting to see what the students do with them. I'll write some black-box sub-vis encapsulating the Wiimote-specific code and make the Wiimote accelerometer traces accessible as outputs. Then we'll let the students do some LabVIEW coding on their own and see what they come up with.

Hello! I've been away from the forums for some time now but now I'm back. I've been making the final push on my doctorate and I'm finally done! I defended my thesis on Monday and the committee passed me. I'm walking around in a state of shock. I've been working on this for a long time while holding down a full time job as support engineer/lab manager here at the University of Michigan and it is hard to believe that it is finally done. If anyone wants to know about how to use particle image velocimetry to measure the velocity vector fields of polymer melts during injection molding, I'm your man. This also means that I'll be starting a job hunt in the next month or so. I'll post something in the Jobs forum when I'm ready to start the hunt, but if anyone out there is interested in a mechanical engineering PhD/CLA/CPI/PE then PM me. But for now, I'm going to concentrate on catching up on all the sleep I've lost this past month or so.

How about a list of the "Most Dangerous LabVIEW Programmers"? :laugh: QUOTE (PaulG. @ Jan 13 2009, 03:59 PM)

QUOTE (TobyD @ Aug 28 2008, 03:54 PM) Nice work. Your application fulfills the requirements and the spirit of the exercise. But I'm going to ask you to make one more attempt at it. In your solution you use a functional global to communicate between the loops. That works, but it is not the way that it is demonstrated in the Advanced I materials or in the LabVIEW Style Book. There is a way to set up the architecture so that you don't need the functional global. That makes the app simpler and in better style. You probably figured out that if the error occurs in the producer loop it is pretty straightforward to shut down both loops. That's because the whole point of the producer-consumer architecture is that the producer communicates with the consumer through the queue. The real problem occurs when the error occurs in the consumer loop. There is no built-in method (like the queue) for the consumer to communicate "up-stream" to the producer to shut the producer down. In your app you used a functional global to do this. Instead, try to take advantage of the event structure in the producer loop. Make the consumer loop do something that the producer loop event structure will recognize and respond to. Here are two possible ways to do this. One way is to use the Value(Signaling) property of the Stop button. Another is to generate a user event in the consumer loop that the producer loop can respond to. My suggestion to you is to try the exercise once more and use one of these methods to shut down the loops on error instead of using the functional global. Again, good work! I'm glad that you are finding this exercise helpful.

Dragging the thread kicking and screaming back to its original topic, the poll has closed and the results are in. 37% voted for 2 years, 33% for 3 years, 16% for 4 years, 12% for "Once certified, always certified". Twenty-four votes were cast.

QUOTE (TobyD @ Aug 26 2008, 03:00 PM) I made the suggestion about the type def enum because it is my guess that that is what the CLA exam graders will be looking for. The enum is easily scalable, and the CLA project is supposed to be large enough that a string wouldn't be appropriate anyway.

QUOTE (TobyD @ Aug 26 2008, 12:24 PM) I reviewed your vi and I have some constructive criticism for you. Normally I would have tried to PM you privately, but since you posted your solution publicly I'll make my critique public as well. I hope you don't mind! Your vi does perform as I specified, but now I realize that I wasn't quite specific enough about the P Error and C Error buttons. My intent was that the P Error and C Error buttons (and their corresponding event and case structure cases) only trigger the user-defined errors. The intent is that by pressing the button you introduce an error into the error chains of your architecture. The point of the buttons is to see how your architecture responds to the errors. In real life you never know where the error will hit. In this exercise you do know exactly where the error occurs, but you should pretend that you don't know. In other words, queuing a "Stop" command in the same event case where you generate the P error is not allowed. Sending a boolean true to the producer continuation terminal in the P Error event case is not allowed. The only thing the P Error case should do is generate a P Error. The fact that the error propagates through the error chain should somehow stop both loops. Sending a boolean true to the continuation terminals of both loops when you generate a C Error is also not allowed. The only thing the C Error event case should do is queue the C Error state of the state machine. The only thing the C Error state of the state machine does is generate the C Error. The fact that the error propagates through the error chain should somehow stop both loops. Another tip. Part of the exercise is to make the code shut down gracefully in case of error. What I meant by that is that when an error occurs the state machine should somehow execute the Stop state to release the queue and shut down normally. When your vi shuts down on a C Error it never executes the Stop state. A final style tip. When you build a state machine it is recommended that you use a type def enum as the state specifier instead of a string. It has many advantages. The labels show up as identifiers in the case structure, and when you modify the type def all instances in the vi get updated at the same time. One last suggestion. Insert the "General Error Handler" or "Simple Error Handler" vi between the Merge Error vi and the error out. Other than that, it is a good, clean looking vi. I like the way you did your loop labels in the same color as the loop boundary. The comments and labeling are good and the diagram is easy to read. I suggest reviewing the producer-consumer architecture in the LabVIEW Style Book and/or the Advanced I material to get ideas on how to use the error chains alone to shut down both loops in case of error. I'll update my blog post to try to make the intent of the exercise more clear. Thanks for being my experimental subject!

QUOTE (Gabi1 @ Aug 25 2008, 03:52 PM) You can buy a product called http://www.novii.tv/' rel='nofollow' target="_blank">Novii Remote that will do what you are asking. Of course it isn't "DIY", but if you want something RIGHT NOW, give it a shot.

I've been thinking about that "real programmers" thing. One of the great things about LabVIEW, IMO, is that it doesn't have that "programmers culture". Most LabVIEW programmers are engineers and scientists who use LabVIEW to do things, not CS types who argue about the purity of the language. But this also has its drawbacks. Because most of us are not CS types, we also don't have a background in things like programming style and programming best practices. That's why I think certification is important. Taking the certification training fills in the gaps. It teaches you about good style and good practices (documentation, source control, etc.) without creating a "computer-snob" culture to go with it.

QUOTE (TobyD @ Aug 25 2008, 01:18 PM) Hey, that was fast! Speed is good! So, did you fill out the tip strips on all your front panel objects, fill out the VI Documentation, create a pretty custom icon, put comments in each case of your structures, label significant wires and do the whole thing in a LabVIEW Project? Seriously, though, one tip I would pass on is to not forget everything you had to learn for the CLD exam. Documentation and style are still two of the areas graded, even if they are assigned fewer points than they are in the CLD exam.

QUOTE (Chris Davis @ Aug 25 2008, 11:22 AM) CLAs would be able to grade either CLD or CLA tests, CLDs could grade CLD tests. And yes, compensation is an issue. I having a certification board reduced the load on NI personnel then a fair compensation would be win-win for everyone involved. My suggestion was aimed at getting a larger pool of practicing application engineers involved in grading and creating the certification exams. I think that it would be an improvement over having a small pool of currently non-certified NI personnel responsible for the grading. For one thing, practicing application engineers have more LabVIEW programming experience and are more likely to be on the "cutting edge" of best practices and style. The current LAVA 3-button dialog coding challenge is a good example of this. A community that cares that deeply about LabVIEW style and practice could provide a number of graders and test-creators as qualified, or better qualified, than the internal personnel that NI currently uses.

There's a new post on The Paper Chase that will be of interest to people preparing for the CLA exam. One of the difficulties of preparing for the CLA exam is that there are no sample exams on the NI website. So I came up with a parallel loop coding exercise to help me understand (and code) a basic producer-consumer architecture. It helped me, it may help others. So stop by and check it out! Note: I came up with this self-test before I took the exam, so it should not be a violation of the NI non-disclosure agreement.

If you go to the NI website and look at the comments people have left on the pages that link to the CLD sample exams you'll see similar complaints. You can download NI's proposed solutions to the exams, and they have some problems. For example, one of the test criteria is that your solution not eat up 100% of the CPU, and the solutions have loops that don't have Wait functions built into them. That's one of the reasons why I was advocating an external board to help grade certification exams. An external board would have more practical LabVIEW application programming experience than most NI employees, and would be able to pick up on things like this.

I see your point, and I particularly like your idea about ending the file names in .g, but I'm not going to hold my breath waiting for changes. I was having a similar conversation with our local NI manager and ASTDan the other day after a user group meeting. I see the distinction between LabVIEW and G, but I think that it is a distinction with little meaning. As long as G is proprietary to NI, and as long as the only way to program in G is to use LabVIEW, then the two will be synonymous. Now, if G was an open source language and you had choices like LabVIEW G, ANSI G, Borland G etc. then it would be different. Or maybe if it wasn't open source, but you had different flavors of G like G, G++, G# then it would make sense. But right now G=LabVIEW for me, and distinguishing between the two isn't worth the effort.

QUOTE (Khalid Ansari @ Oct 25 2005, 01:39 AM) \begin{shameless_plug} Correct! For more information, see my http://bress-paper-chase.blogspot.com/2008/08/ni-begins-to-eat-its-own-certification.html#links' rel='nofollow' target="_blank">blog! \end{shameless_plug}

QUOTE (crelf @ Aug 21 2008, 03:34 PM) Actually, I don't know. I haven't had to recertify yet, ever, so I don't know what is involved. I've always gotten the next higher certification before my old one ran out. Does it cost money? What are the recerts like for each level of certification?

QUOTE (LV_FPGA_SE @ Aug 21 2008, 01:18 PM) Another idea would be for NI to set up a Continuing Education Units (CEU) system. Go to a user group meeting, get a small number of CEUs. Give a presentation at a user group meeting, get a larger number of CEUs. Accumulate them for going to Developer Education Days, NI Week, taking training classes, etc. If you meet a certain target number of CEUs during your certification period you don't have to take a recert test. If you don't meet the target you do take the recert test.

QUOTE (eaolson @ Aug 21 2008, 11:08 AM) I typically take the offending non-error-propagating native function and wrap it in a sub-vi wrapper that has error cluster propagation, like the OpenG Wait function. Then I can use it in the future as well without resorting to sequence structures.

I agree that sequence structures should be avoided if possible. But here's what I want to know. If sequence structures are so bad, why do they figure so prominently in the LabVIEW logo? The logo is an Add superposed on a sine wave sitting in a big fat sequence structure frame!