Sending a Character through Serial

[WMassey]

I had mentioned previously (embedded in the VI comments) that you should shove some of your block diagram functionality down into a send-command subvi. I have attached an example of what I am talking about. Here is what it looks like when it is used in the main VI:

Download File:post-2800-1142860798.zip

[zero-tolerance]

I have changed it to what you suggested, it greatly improved the look of it. Is it something of this sort that you had in mind.

I took the 'OC' command off from the idea that I had by comparing the output to the input since I checked it with the supervisor and he said the same thing as you had. Never the less from this last program that you had posted i managed to learn the use and the importance of the LOCAL VARIABLES as I never knew what this was. but since you kept using it quite a bit then I studied it untill I understood what it did. I know it must be a very simple thing but it proved to be quite a powerfull function.

P.S Your comments on the previous code were of great help. Specially the part where you sugested to use a sign inverter rather than what I had, you had labelled it as '***'. Sorry I never knew that such function existed, even though I've seen it many times.

Many Thanks.

Download File:post-4068-1142991591.zip

[WMassey]

I have changed it to what you suggested, it greatly improved the look of it. Is it something of this sort that you had in mind.

I took the 'OC' command off from the idea that I had by comparing the output to the input since I checked it with the supervisor and he said the same thing as you had. Never the less from this last program that you had posted i managed to learn the use and the importance of the LOCAL VARIABLES as I never knew what this was. but since you kept using it quite a bit then I studied it untill I understood what it did. I know it must be a very simple thing but it proved to be quite a powerfull function.

P.S Your comments on the previous code were of great help. Specially the part where you sugested to use a sign inverter rather than what I had, you had labelled it as '***'. Sorry I never knew that such function existed, even though I've seen it many times.

Many Thanks.

Yes that does look better and it is indeed easier to follow what the code is doing.

Actually I felt a bit ashamed of my use of the two variables inside the while loop back in my attachment to this post since the same values were available from the controls themselves further to the left in the loop. It was just a case that the path for the two wires from the locations of the control terminals to where I needed the values was rather long and twisty (or else hidden) and I thought that the local variables would make it a bit easier to understand. On the other hand, the two local variables on the outside left of the while loop being used to initialize the feedback nodes is a good example of the proper use of local variables. You have to be careful with locals, they are almost as easy to abuse as they are to use. They can make it harder to follow the data flow through a system. And how's this for a thought, I have my VI Engineering Advanced LabVIEW Development course manual (Feb 2001) here in front of me and it says "Reading from a local variable can be up to 400 times slower than reading from a shift-register." Sometimes they truly are the right tool for the job but you need to be sure of that first.

[zero-tolerance]

Hi again Warren. I'm having a problem with the speed of the program that is executing. I think its because I am sending the "OC" command constantly and LV program is bussy all the time by trying to cope with this command. When I press the other buttons to check for the Status of the motor, or to reset it, or actually any other buttom then it takes quite some time before the commands are sent through and even longer for a reply from the PM341 device. I tried to send this command continuesly every 30 (ms), but I couldn't comme up with an idea how, since I havent dealt with timing issues before I am finding hard to do this.

What I also need is for the messages of the PM341 when I recieve them to be displayed in 2 different sections. i.e. when I'm constantly monitoring for the position by the "OC" command I recieve a message like "01#23574" where "23574" is the position of the motor where I then Convert it to length, so that the user can see the "bar" sliding up and down, as well as numerically displayed. When I now press the "RESET button it resets the PM341 device and I recieve a message "01#OK", but I want this message to be displayed in a different place. there are all other different comands that I am using but they can all be displayed in one field appart from the position command which is the "01#23574".

What I have done on the previous attachment NEARLY does the job but when I press the "CHECK STATUS" button I recieve a messages like "01#0000000000" to say that there are no errors and the motor is ready to be moved and this reply is always a 13 bit number but at the same time because all of the zeroes the place where I say "Motor X position" as well as the bar goes back to zero untill the "OC" command is sent and then I read another number.

Is it possible for this to be done so that even though the "OC" command is constantly sent to the PM341 and during this time the user checks the motors status and then I recieve a message like "01#OK" and I want this message to be displayed to the user for at least 2 sec. even though I keep recieving the position of the motor continuesly. It would be nice for this 2 second rule to apply to all other messages that I recieve except the message that comes in the form of "01#23389 etc".

I tried doing this by using different functions such as "Scan from String", as well as monitoring the length of the string so that if its bigger than 13 bits than I would display this message some place else, but I just couldn't get it fully working, which I guess I couldn't come up with a way of connecting these functions together.

Thanks

[WMassey]

What you are asking for involves a bit of complication because you are demanding that your system assume various states depending on whether or not some event occurred and then it needs to remain in that state until some other (timer) event occurs. That "complicated" (your word, not mine) state machine I posted 30 or 40 messages back could be easily modified to handle stuff like this, but it's also possible to add some logic to your existing VI to do it too. Take a look at the attached VI. It'll give you an idea how you can handle timed events. Instead of blinking lights, think "OC" command. I wouldn't be surprised if others suggested better ways to do this.

Download File:post-2800-1143163097.vi

[zero-tolerance]

Hi Warren, this question is out of curiosity.

Untill now I have only been involved in sending and recieving bytes through pin 2 and 3 of the serial link. Does LV support the idea of controlling each individual pins on the serial port. I.e. I only use pin 2 & 3 to send and recieve, but what if I want to use pin 4 of the serial port to just send a single bit ( a binary 1 ). Im not sure how I could get a more of a HARDWARE controll over the serial port pins. any idea?

[WMassey]

Hi Warren, this question is out of curiosity.

Untill now I have only been involved in sending and recieving bytes through pin 2 and 3 of the serial link. Does LV support the idea of controlling each individual pins on the serial port. I.e. I only use pin 2 & 3 to send and recieve, but what if I want to use pin 4 of the serial port to just send a single bit ( a binary 1 ). Im not sure how I could get a more of a HARDWARE controll over the serial port pins. any idea?

Pin #4, let's see, according to the 9-pin RS-232 spec, pin #4 is the DTR (Data Terminal Ready) pin (see the Serial Quick Reference guide found here).

This is something I didn't know you could do until I just now went here and did a search on these three words: control DTR pin which turned up this posting (along with several others).

The search pages, both here and at NI should be everyone's first stop when trying to find out something you don't know.

Anyway, this appears to be how it would be done.