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.