Sending a Character through Serial

[zero-tolerance]

Hi everyone, i am trying to send a string of characters "01OS" and "01RS" through the serial interface to a device called PM301. when i connect the device to the serial port without even sending anything i start getting rubish readings on LabView but when i connect it through the Hyperterminal then I dont get any of those readings. what i should really have in return from the device is "01#ok" no matter which one of the above commands I sent but i dont get that, instead on LabView I am Flooded with some none-sense readings. the device i am talking to only understands characters like the above commands.

What i am worried about is if LabView is sending to this device something on the background as soon as I run it i.e. without my knowledge becuase i dont get any of the rubish reading through hyperterminal. the serial port settings are :

Baud rate 9600;

Data bits 7;

Parity: EVEN;

and no handshaking is require with the device i.e. the device only has three wires in its serial port, the read pin, the write pin and the ground.

anything is welcomed ..... AND Thankyou in advanced

[Louis Manfredi]

Hi Z-T:

I've done a fair bit of serial port programming with LV-- Never recall a problem with LV sending out stuff that I didn't want it to send, so I wouldn't worry too much that that's the problem.

Your problem sounds an awful lot like a hardware connection problem, or a baud rate/ port configuration problem--- Except that it works in hyperterm. Are you running hyperterm on the same machine as Labview so you're certain the hardware is identical? Are you absolutely certain all your LV and hyperterm port settings are identical? Are you exiting Hyperterm before you run the LV program to be sure that there is no resource conflict?

You've probably been through all these questions yourself already, but if not a good place to start.

Good Luck, Louis

[zero-tolerance]

I have actually gone through them allready. I've spent a whole day trying to find the problem but i couldnt see anything apperant. The one thing is bothering me is that when I run it through Hyperterminal I cannot see what i'm writing but its there in a invincible mode, and as soon as I pres [ENTER] the commands go through and I get the right response from the motor. But through Labview I cant see anything reply at all, whereas when I talk with the same LV program to my own Hardware device I can actually see read what comming and everything.

Abother problem that i am facing with LV is when I recieve the message on the screen the old message does not get replaced with the new one. E.g. when I reset my hardware a message comes on giving about 3 choices to the user and when the user enters the desired choice it goes to another menu, but LV does not replace the old message or the old menu. is it possible to do this or have you allready got an exammple that you can shown me.

It'll be really hellpfull, thnx.

[Khalid]

Hi,

This is my typical solution to such problems: download Portmon (or any other such tool) and monitor the actual bytes going out from the HyperTerminal, and compare it with LabVIEW's. You will be able to find some discrepancy this way.

http://www.sysinternals.com/utilities/portmon.html

In Portmon, I find it easier to work if I set the mode to HEX, and filter unnecessary commands and just get the READs and WRITEs.

Hope this helps.

-Khalid

PS: as for not seeing what you're seding in HyperTerminal, there's a setting to "Echo typed characters locally," under ASCII Setup -- this should do it.

[zero-tolerance]

Another problem that i am facing with LV is when I recieve the message on the screen the old message does not get replaced with the new one. E.g. when I reset my hardware a message comes on giving about 3 choices to the user and when the user enters the desired choice it goes to another menu, but LV does not replace the old message or the old menu. is it possible to do this or have you allready got an exammple that you can shown me.

It'll be really hellpfull, thnx.

[WMassey]

zero-tolerance,

Your descriptions of the problems that you are having leave a bit to be desired. :thumbdown:

If you really want help from this group, you are going to need to reduce your code to the bare minimum that it takes to replicate the problem(s) and then post it here for us to look at.

There is an added benefit to this --- often in the process of reducing the code to the bare minimum, you will find the cause of the problem and its solution yourself. :thumbup:

Been there. Done that.

[zero-tolerance]

I have attached the code of what I have done so far. Im new to the LabView hence even though the solution might be simple i cant figure it out, otherwise i wouldn't be posting for help for such a simple problem.

Anyway I have explained of what the problem is above and if anyone cares to have a look and help me out here i would appriciate it. thankx in advanced.

Download File:post-4068-1139758233.vi

[WMassey]

Well one obvious thing with regards to the garbled communication jumps out at me when I look at your VI. You don't set values for the VISA serial setup and the values you say that this thing uses are not the default values that the serial setup VI uses. The bits per character and parity both disagree. You need to at least specify those values to the VISA Serial setup VI (and it's not a bad idea to specify everything else as well so that there is no question about what values are being used!)

I Googled PM301 RS232 and came up with links to a motion controller. A manual for one was found here and it mentioned the same serial setup you quoted in your first message so I'm guessing this is the device you are trying to talk to.

Assuming I got the right instrument/manual it looks like the commands you send to it need to start with a device address and end with a carriage return character. I've setup your VI so that happens -- you just have to enter the command and press send. The instrument responds back with a message that ends in a carriage return & linefeed. You can enable the VISA serial to hang on a read until it gets a termination character -- in this case it is the linefeed character. You can use the number of bytes at the serial port to tell when a message is starting to arrive but, unless all your messages are the same length, it's not so good to use to tell when they are finished arriving. So take advantage of the fact that the VISA will watch for a termination character that the controller so conveniently uses.

The way this'll work in your VI is like this:

it'll sit there waiting to see some number of bytes in the input buffer;

it'll start the read and the read will terminate only after one of these happens:

1) a termination character arrives (in this case a linefeed)

2) 250 characters have arrived (not likely and not really desired)

3) a read timeout, in this case 10 seconds

For any normal messages, #1 above is by far the most likely way that the read will finish and that will get you one complete reply from the instrument. If there's another one inbound, it'll get picked up on the next loop.

See how this revised VI works out and report back.

Download File:post-2800-1139796173.vi

[zero-tolerance]

Sorry for the late reply but the only place I can test the program is at University.

When I tested that modified program for some reason it didnt do anything at all, even though as you said that i can just send the comands as usual it didnt pick up anything and i didnt recieve anything neither. The LV program never terminated neither. Looks like it was waiting for 250 characters on the buffor or something. One thing that i totally forgot to test was the portmon program to check that what am i actually sending through the hyperterminal and what am I sending through the LV. apart from that i have no idea.

Please let me know if you have any other tricks that might solve this matter as I onyl have 1 month to go.

thnx again

[orko]

Sorry for the late reply but the only place I can test the program is at University.

When I tested that modified program for some reason it didnt do anything at all, even though as you said that i can just send the comands as usual it didnt pick up anything and i didnt recieve anything neither. The LV program never terminated neither. Looks like it was waiting for 250 characters on the buffor or something. One thing that i totally forgot to test was the portmon program to check that what am i actually sending through the hyperterminal and what am I sending through the LV. apart from that i have no idea.

Please let me know if you have any other tricks that might solve this matter as I onyl have 1 month to go.

thnx again

Two things I may suggest when testing WMassey's VI are:

1) make sure you are selecting the proper VISA resource name for your system for COM1 on your system. Unless you have aliases already set up, it will most likely be something like "ASRL1::INSTR".

2) Make sure you wait at least ten seconds after hitting "send" before giving up on the reply. That is what the timeout is set to in the configuration here, and since you said you probably are only getting back ~5 bytes, you'll hit the timeout for sure unless you lower the buffer to something less than 5 (although I would lower the timeout myself).

HTH,

Joe (orko)

[WMassey]

Two things I may suggest when testing WMassey's VI are:

1) make sure you are selecting the proper VISA resource name for your system for COM1 on your system. Unless you have aliases already set up, it will most likely be something like "ASRL1::INSTR".

2) Make sure you wait at least ten seconds after hitting "send" before giving up on the reply. That is what the timeout is set to in the configuration here, and since you said you probably are only getting back ~5 bytes, you'll hit the timeout for sure unless you lower the buffer to something less than 5 (although I would lower the timeout myself).

HTH,

Joe (orko)

I agree with what Joe suggests. And by all means, feel free to lower the timeout value -- I just left it set to the default. If you force the read to terminate on a low byte count that just means that something is wrong somewhere and you are trying to artificially cover up the problem. Identifying and fixing the problem is what is really needed. Don't go to a low byte count just to make the read complete! Was I correct about my guess at the nature of this device? A McLennen motion controller? Unless I misread the document, it said that all replies would be terminated by a LineFeed. Correct? If all that is correct then the VISA "read" should be able to teminate on LineFeed characters if everything is working properly.

One other thing you should definitely try is to shutdown HyperTerm and instead startup the National Instruments "Measurement & Automation Explorer" (M&AE).

Select "My System --> Devices & Interfaces --> Ports (Serial & Parallel) --> Com1 (or whatever) -->

Port Settings --> (setup the appropriate communication parameters) -->

General --> Device Enabled (checked) --> Open VISA Session --> Basic I/O

and using the "Write" and "Read" tabs you find there, try communicating with the device.

If you cannot get communications working here then you cannot get it working in LabVIEW.

Also keep in mind that the M&AE needs to be shut down (as does the HyperTerminal connection to the Com Port) before the LabVIEW program can use the port.

And as far as the LabVIEW program not terminating, you do realize that the while loop will not end until you either get an error back from the VISA system or until you press the quit/stop button don't you? If it is not doing that properly, then you need to turn on execution highlighting and see where it is getting hung up and report that back here.

FWIW, I tried downloading and running the example VI that I posted the other day against another serial device and, once I adjusted for the correct communication parameters and command format, it had no problem sending commands to the device and reading and displaying the responses it produced. So the VI does work in its basic format if the communication parameters and command format are correct for the device.

Please let me know if you have any other tricks that might solve this matter as I onyl have 1 month to go.

You may want to consider moving this discussion to the Info LabVIEW forums here if for no other reason than the server(?) for the LAVA forums seems to be rather flakey lately.

It will also get you another set of opinions as to what your problem might be.

[zero-tolerance]

hi guys again, its just that I have been so busy doing the report lately i havent been able to respond back.

WMassey ---> You were correct about the nature of the device, and thats the actuall Manual that i use for this device.

One thing that I coudn't come accross in that manual is the all the replies being terminated with a line feed, i just

coudnt find exacly what type of termination character it uses or but I wouldnt be surprised if it doesnt use one.

Oh, and i do make sure not to make the simple mistakes like, leaving the Hyperterminal on while using LV and vise versa.

One thing that is bothering me are these reply terminations, and the transmitting part.

I just dont seem to know if I need to send something else before I actually transmit my commands, because i know for sure that i cannot trasmit the comand as the motor is not moving at all, even though i dont recieve anything the transmitting part isnt working either.

e.g. when i sent "MR10" to the device it should move the stepping motor straight away and this does not happen with LV, whereas when i use the same command with Hyperterminal it works perfectly (even though it does not echo back the command that i am sending, but it does get the motor moving and i do recieve the messages back stating its status i.e. ussually i recieve "01#OK" if i send the command "01RS").

[orko]

Have you comfirmed the VISA resource name in MAX and timeout value? WMassey's VI ran perfect out of my serial port with the proper VISA resource name, although it did take 10 seconds (for the timeout to kick in).

I also was wondering if you tried to communicate with the device from MAX (Measurement & Automation eXplorer).

Joe (orko)

[WMassey]

One thing that I coudn't come accross in that manual is the all the replies being terminated with a line feed, i just

coudnt find exacly what type of termination character it uses or but I wouldnt be surprised if it doesnt use one.

On page 21 of the manual from here (a better link I think) it says:

"REPLIES

Response to a command is either an OK string or an alpha-numeric string once the command has been accepted.

Responses terminate in carriage return (0D) and line feed (0A). If an error situation is created, an error message

appropriate to a mistake or conflicting instruction is sent. The first character of an error message is !

These replies are preceded by the axis address from where the response came from, and a hash symbol, e.g.

1#OK (useful in a multi-axis system)."

You absolutely MUST get this working in the Measurement & Automation Explorer before it will ever work in LabVIEW.

M&AE establishes some of the settings that LabVIEW subsequently uses when your code is run.

[zero-tolerance]

Its great, I finally got it moving. the problem was that it was duplicating the comand that i was sending i.e. when i send "01RS" the actuall characters that were being sent were "0101RS" and hence i coudnt see anything. this was due to the "Device address" that you built on the front pannell. I had no idea that when selecting the Device address 1 the "01" part of the command was allready there to be sent, and when selecting the Device address to 2 the part of the command "02" was ready to be sent, and when I was sending the whole command "01RS" or "02RS" I ws actually sending "0101rs" or "0202RS".

Anyway it works perfectly now. Thankyou :worship: .

I know it was my fault as I should have known how to use that program from the beggining .

What I am about to ask for might be too much from you guys (specially from "WMassey" as he was the one helping me the most), but I was given this project from out of the blue, I had never done or even heard of the programm called LabView before, I only have from today 32 days remaining and this counts for 20% of my whole year of the university. I am finding it extremely difficult to understand this software even though i admit its easier then most of the others like "C, or C++ etc" as this software is more sort of graphicall use. I my self am an Electronic engineer, I am good with electronics and "assembly" programming, which is a programminglanguage for electronic chips like Microcontrollers etc. but i have absolutely no idea on LabView.

I would be most greatfully if anyone (including "WMassey") could spend a little time helping me out, as i am very very short of time especially when i have a mounten of other reports and coursework to do.

Thankyou form for everything that anyone can offer especially i would like to thank "WMassey" for his time with me for this past week, as he actually wrote a fully functunal program for me, and helped me out to the fullest. Top Man, thanx.

This project however wasnt going to be as easy as this for me, to complecate matters more, i will eaplain the rest below:

1) I need to make the user Interface part i.e. the front pannel so that when the user clicks a button (lets call it "Ceck Status

"X"" for motor X and "Check Status "Y"" for motor Y) the message "01OS" will will be sent to the motor "X" and message

"02OS" will be sent to the motor "Y" when those buttoms are clicked. On the reply we would recieve the message

"01#0000000000" and "02#0000000000" respectivelly. If however one of

the bytes in red happen to be high i.e."1" then the command "01RS" or "02RS" (depending which motor it is "X" or "Y")

would be sent automaticakky, and that would reset the motors back to default, because if any of those bytes are high then

this means that the motors are busy or there is some sort of an error in them, hence cannot be moved.

2) After the first point is done the second part of the header should then be sent automatically, i.e. the command "01SB300"

should be sent first, then "01SV6000" for motor X, and "02SB300" should be sent first then "02SV6000" for motor Y

(depending which button was clicked by the user at the beginning. If everything has gone smoothly on the above points,

there should be a "green light" for each motors i.e. for X and Y and if this initialization wasn't done properly there should be

a "red light" for both motors, indicating that something has gone wrong depending which motor was used.

3) The first and the second part of the points above were to make the motor ready i.e. to set them up. Now, if everything went

OK then the command "01MRxxxx" or "02MRxxxx" would be sent at the

end depending which motor the user is using. The reason why I marked the "x" part in red is:

a) The motor "X" wors in steps, hence its a stepping motor. and for this, the user would only have to enter a

length in "mm" and this number would have to automatically convert in steps and then that answer should

replace the red "x" shown above. This particular motor has 800 "steps" per "mm". E.G. When the user

enters 5.00 (which means 5.00 mm) the value "4000" should replace the red "x" above. or when the user

enters 1.26 (which means 1 mm) the value "1008" should replace the red "x" above, i.e. this is done by

doing "1.26 * 800". This can however go up to 2 meters at maximum, and no more.

b) The motor "Y" works in the similar way as motor "X" works but instead the user here enters an angle rather

than a length in "mm". And here this motor has 300 "steps" per "degree". E.G. When the user enters 25.30

(which means 25.30 degrees) the value "7590" should replace the red "x" above. or when the user enters

27.00 (which means 27.00 degrees) the value "8100" should replace the red "x" above. This can however go

up to 360.00 degrees at maximum, and no more.

4) When the user enters the data at the end the red "x" on the command should now have numbers in i.e. lets say that the

user enteres 2 "mm" for the "X" motor, then the last command "01MRxxxx" should be "01MR1600"

and this should automatically be sent at the very end. and this would complete the whole lot.

Below is an attachement of the program that communicates with the hardware called PM341, which WMassey built it for me.

This program only works when i sent the actuall commands i.e. when I select device address 1 and send the command "RS" I recieve a reply "01#OK" because I am actually sending "01RS" (which means I am talking to the "X" motor) and when I select device address 2 and send the same command, then I recieve "02#OK" (which means that I am taslking to the "Y" motor).

Download File:post-4068-1140125689.vi

[zero-tolerance]

I managed to do the 1st point above somehow, even through its not exacly what i needed, but I really am scared about the third point, I have no idea how to even start with that. Could anyone please help me out a little. thats the hardest part that I am facing so far.

Thnx in advanced.

[orko]

I managed to do the 1st point above somehow, even through its not exacly what i needed, but I really am scared about the third point, I have no idea how to even start with that. Could anyone please help me out a little. thats the hardest part that I am facing so far.

Zero,

I'm afraid that is way too vague for me to try and answer. What is your specific question? The third step in your procedure you outlined looked like pure math, so I'm confused about what it is you want help with?

Joe (orko)

[zero-tolerance]

Zero,

I'm afraid that is way too vague for me to try and answer. What is your specific question? The third step in your procedure you outlined looked like pure math, so I'm confused about what it is you want help with?

Joe (orko)

Ok, there should be two buttons that the user can click depending which motor will be used. For example, button 1 can be called "Initiliazing Motor X" whereas button 2 can be called "initiliazing Motor Y" dependging on which button is pressed a certain commands are sent to the motor automatically (Please read the previous page where the 2st point as well as 2nd point are explained that how these buttons should work and what commands are sent when these buttons are preseed). normally when one of these buttons is pressed a number of commands are sent automatically, but also in the front pannel of the LV there should also be a space where the user can enter the angle (for motor Y) or the length in "mm" for motor (X). Now, when the user enters the angle or the length then yeah, its true that there is some mathematics behind it, but all this mathematics does is turn the length or the angle at which the user has entered into the number of steps, so that its ready to go to the motor, but the only way that the motor will understand is when the whole command is sent i.e. 01MR2959 or 02MR2358. The reason the numbers are in red is that this number represents steps of whatever angle or length the user has entered whereas the part "01MR" and 02MR" are there always constant depending which motor the user was using. So when the user enters the length or the angle it is then converted into steps, once this number is converted into steps the whole command "01MR2342" or "02MR3445" (depending which motor) should be sent, otherwise the motor would not understand that it should move by "2342" or "3445", hence the command "01MR or 02MR" should always be before the number of steps is sent through. So, the final result should be "01MR2342 or 02MR3445", where as the part "01MR or 02MR" should not have been entered by the user. This part should always be there as a constant behind the "SEND" button so that when the user enters the value and presses "SEND" the this value should undergo under these mathematical changes so that this value is turned into the number of steps and the at the end this final number should be joint together with the command "01MR or 02MR" and then finally the whole lot "01MRNo.odSteps or 02MRNo.odSteps " (depending which motor we are talking with) should finnally be sent all together through the serial. So this is the part which i dont know how to do.

Talking to the motor is allready set up. The program that I am using so far has been uploaded on the previous page, so please see if you can take sometime and help me out a liitle.

I really approciate your help, thanks.

[orko]

Thanks for the clarification. What it looks like you needed then was an example of how to format a string conditionally based on the user input, so you get the correctly formatted command out to the motor. The attached example uses a "ring" to select which motor you want, and calculates and formats the string before storing it into a string.

Let me know if this is enough to get you going and if any of this doesn't make sense to you. It looks like putting this together with the logic that WMassey gave you should get you the desired results, with a little tweaking. You should be able to take it from here

Download File:post-3266-1140387314.vi

Joe (orko)

[zero-tolerance]

Thanks for the clarification. What it looks like you needed then was an example of how to format a string conditionally based on the user input, so you get the correctly formatted command out to the motor. The attached example uses a "ring" to select which motor you want, and calculates and formats the string before storing it into a string.

Let me know if this is enough to get you going and if any of this doesn't make sense to you. It looks like putting this together with the logic that WMassey gave you should get you the desired results, with a little tweaking. You should be able to take it from here

Download File:post-3266-1140387314.vi

Joe (orko)

Thanx for that "orko" but for some reason when I connect your program with the WMassey program that gave me it doesn't work properly. Everytime I run it it keeps sending the command over and over again even though I dont press the "Send" button, but when I press the "send" button it sends several commands straight away, where I only need it to send 1 command per click.

I monitored the output that is going to the serial through PortMon, and the attachement is below together with the attachement of the front panel of the LV program that I was running when I captured the traffic with PotMon.

Below is also the program that I tried modifying.

and yea, its exacly what I needed. Many thnx for the help.

Download File:post-4068-1140397712.vi

[WMassey]

It's somewhat hard programming for hardware that you don't have access to but the attached (LV v7.1.1) motion controller system will give you a good start toward what you say you need. I'll leave it to you to debug it since you do have the hardware. Enjoy.

B.T.W., you may need a fairly recent copy of WinZip to unzip the file because I used a maximum-deflate option to minimize the file size and that option is not as portable as the normal deflation options.

I have had a bit more time to do some testing of the stuff I put together and found one problem (it probably isn't the only one, the testing has been limited) with the way I was handling the global commands. I fixed it and have I have uploaded a replacement zip file. Note that the code comes with a VI which I usually build into stuff like this that allows for the monitoring and display of the exchange of commands and responses between the LabVIEW and the object being controlled. You may find it useful. I know you asked for just the ability for doing relative positioning but I threw in absolute positioning as well since it was not hard to add given the way things were built. Keep in mind that absolute positioning is only as good as your position reference and you didn't ask for (nor did I provide) a homing routine to establish that reference. Homing really is hardware dependent and I don't know any of the fine details of your setup. I did provide the ability to zero the axis position which is often the last step of a homing routine so if you get the axis to what you would consider to be a good zero point and then zero the axis position, you will have your reference for absolute positioning. Look at how the zero-position function works and you can see how to modify it so that, instead of zero, you can define the position to be any value. You also didn't ask for, nor did I give you, an axis jog function. But, it's not to hard to add jogging (and an accompanying speed control) to a structure like this. I did give you a STOP motion button that may prove to be useful at some point. I didn't worry much about the look of things. I'll leave it up to you to take care of all that.

I hope it works for you and that you learn a bit more about LabVIEW getting it working for you. If nothing else, it demonstrates the flexibility of the state-machine approach to programming.

Warren

Download File:post-2800-1140520628.zip

[orko]

Thanx for that "orko" but for some reason when I connect your program with the WMassey program that gave me it doesn't work properly. Everytime I run it it keeps sending the command over and over again even though I dont press the "Send" button, but when I press the "send" button it sends several commands straight away, where I only need it to send 1 command per click.

Sorry about that. I was hoping to eliminate occurances or using an event structure, which I normally do but wasn't sure if you had any knowledge of yet. That'll teach me for trying to skip steps

With WMassey's package and the vi's that have been given to you, I think you should have enough to get the job done. If not, please look at event structures and/or occurances to make my example work a little better. Sorry I don't have time right now to put together an example for you, but will later in the week if you need it.

Good luck!

Joe (orko)

[zero-tolerance]

Well, after this, I really am left speachless, Its really very very very close to what I needed exacly. There aren't any words that I can put it on how I feel but nevertheless I would realy really like to thank Warren (Wmassey) for actualy spending so much time and actually getting it to work as well as other members for putting their thoughts and actually helping me out big time. :worship:

When I checked at the program, it was so professionally looking to me that I dont seem to have the slightest clue on how to edit things on it to 100% the way that I need it. The program seems to be going loops within loops and I totally lost it.

-------------------MORE IMPORTANT---------------------------------------------------------------------------------------------------------

one thing that I needed to add is the second RS232. this second RS232 which comes out of my Microcontroller goes to COM2 at the back of the PC. Through here I will recieve the angle at which the (Stepping Motor X only) is recieved. Now, I wanted to have a reading of this angle and display it on the main window under the "RUN" tab which Wmassey has made. below I have ilustrated the place where this should be displayed. This is really easy to built, as it does not require any of the fancy "line feed' or "carrige return" because this Microcontroller hardware is built by me hence none of that is required. I am able to talk to my hardware easly by just using the example aploaded below, BUT I just dont have the slightest clue on how to put this on the main program that Wmassey provided me with. "" I'm really dum arent I"" .

Baud rate: 2400

Data bits: 8

No Handshaking required

Stop bit: 1

-------------------------------------------------------------------------------------------------------------------------------------------------

----------------LESS IMPORTANT BUT WOULD INCREASE MY MARKS--------------------------------------------------------------------

The second and hopefylly the last thing that I needed to connect is a Parallel port. On this parallel port I am only using the first three pins. The first pin and the third pin is the left and the right limit of the X motor respectively (which moves in "mm") and the second pin is the ORIGIN of the stepping motor Y. Normally these pins are high i.e. 5 V, as soon as the left or the right limit are touched by the motor then the pins go LOW i.e. 0 V, however as soon as that happens the motor should outomatically stop, and the way to do that is by sending a command "01ST", this will stops the motor. Same goes with the ORIGIN i.e. pin 2, as soon as that goes low the "Y stepping motor should stop via the same command but now 02ST, as that corresponds to the Y motor". When it hits the origine the "Current Position" place which is located under the "RUN" tab would be zero, and then the motor is moved from that position, so the user knows exacly where the "Y stepping motor" is positioned

-------------------------------------------------------------------------------------------------------------------------------------------------

One thing that I actually realised while testing is that the "Relative movement for both motors "X and Y" were not able to accept any positive values i.e. when i enter 5.23 for the X motor, it kept sending 01MR-xxxx where "xxxx" would be the steps. i.e. no matter what I entered it kept converting it to a negative value and then sending that through, whereas the motor actually goes one way when the positive value is entered and the opposite way for the negative value. Sorry if I wasent clear about this at the beginning.

Once again, Many Many Many thanks to everyone especially Warren (Wmassey), as well as orko.

B.T.W. I see there are some doubts going around with the user called "Switesh". He is my partner for this project, at the beginning when i used this forum for the first time i also informed him to use it, but then he was still working on the Hardware side of the project i.e. the Microcontroller board, so now he wants to help me out on LV side. Sorry if this offends or scares anyone , and its only the two of us involved in this project, no one else.

I will post the same program which "switesh" posted earlier on, this was as far as I managed to go when trying to controll both motors. But it shows rouphly of what I wanted to do. the parallel port is not implemented on this LV program because I havent even started doing that side yet.

ONCE AGAIN, I REALLY WANT TO THANK EVERYONE FOR THEIR HELP ON THIS.

Thnx Wmassey and orko too.

Download File:post-4068-1140552344.vi

[orko]

You're very welcome. I hope that you will in the future help contribute to this awesome board!

BTW, there are two things you may want to fix in your final.vi.

1) place VISA Close objects on the outputs of the while loop. You can keep the two indicators if you want them, but closing the VISA sessions prevents possible problems in the future (especially if you make a VI into a subVI or make it reentrant).

2) By the looks of it, you're still sending an empty string to the VISA Write object every 50 msec when the program is idle (when no button is pressed).

Good luck with your project!

Joe (orko)

[WMassey]

I dont seem to have the slightest clue on how to edit things on it to 100% the way that I need it.

Well first of all you need to get into it, turn on execution highlighting and watch how it works. Understanding comes with study. Then you just have get in there, making little changes, testing as you go to see that they are doing what you want them to do.

The program seems to be going loops within loops and I totally lost it.

You need to get a grip then because this is the way most programs work,

one thing that I needed to add is the second RS232. this second RS232 which comes out of my Microcontroller goes to COM2 at the back of the PC. Through here I will recieve the angle at which the (Stepping Motor X only) is recieved. Now, I wanted to have a reading of this angle

Make a copy of the "Yak at McLennan", give it a name like "YAK at Encoder" and configure internally for the communication settings you need and you should be able to use it to get readings from your encoder.

This is really easy to built, as it does not require any of the fancy "line feed' or "carrige return" because this Microcontroller hardware is built by me hence none of that is required.

Don't dismiss the linefeeds and carriage returns so quickly. You need something to separate the end of one message from the beginning of the next!

I just dont have the slightest clue on how to put this on the main program

You need to make the effort!

"" I'm really dum arent I""

I cannot say much for your spelling, but no, I am sure you are not dumb. You are just feeling a bit overwhelmed.

That will go away once you decide that the job isn't going to finish itself (and it is not!, hint hint) and you start in on the work yourself.

---LESS IMPORTANT BUT WOULD INCREASE MY MARKS-----

If you are getting graded on this and if the software figures into that grade then you really do need to consider what you have been given so far as an example of various techniques of how your problem might be solved and use those techniques in designing your own solution to the problem.

The second and hopefylly the last thing that I needed to connect is a Parallel port. On this parallel port I am only using the first three pins. The first pin and the third pin is the left and the right limit of the X motor respectively (which moves in "mm") and the second pin is the ORIGIN of the stepping motor Y. Normally these pins are high i.e. 5 V, as soon as the left or the right limit are touched by the motor then the pins go LOW i.e. 0 V, however as soon as that happens the motor should outomatically stop, and the way to do that is by sending a command "01ST", this will stops the motor. Same goes with the ORIGIN i.e. pin 2, as soon as that goes low the "Y stepping motor should stop via the same command but now 02ST, as that corresponds to the Y motor". When it hits the origine the "Current Position" place which is located under the "RUN" tab would be zero, and then the motor is moved from that position, so the user knows exacly where the "Y stepping motor" is positioned

The limit switches and the origin switch for motor control axes DO NOT GET HOOKED UP TO THE PC!

THEY DO CONNECT TO THE MOTOR CONTROLLER, in your case the McLennan controller. You need to read the manual for the controller!!!

The controller will stop the motion if a limit is encountered and then set a flag which the PC can read (part of the axis status word) signaling that it has happened. The response of the control system to a limit switch needs to be as fast as possible and the motion controller can consistently respond MUCH faster than the PC can. The origin switch is handled the same way; some controllers even come with homing routines built in that use the origin switch.

One thing that I actually realised while testing is that the "Relative movement for both motors "X and Y" were not able to accept any positive values i.e. when i enter 5.23 for the X motor, it kept sending 01MR-xxxx where "xxxx" would be the steps. i.e. no matter what I entered it kept converting it to a negative value and then sending that through, whereas the motor actually goes one way when the positive value is entered and the opposite way for the negative value.

This sounds like a bug to me in the way the relative position values are being handled. Perhaps the code is subtracting A from B when it should be subtracting B from A. You can debug this if you try. Do it this way:

1) With both the front panel and block diagram of the main VI open start it running but don't run any motors yet.

2) Turn on execution highlighting on the block diagram and also press the pause button - nothing will happen yet because the VI is waiting on a user event

3) change a relative position value - that will fire a user event which will immediately be paused

4) while watching the block diagram either "unpause" or single step through the event state that evaluates the relative position value that was entered and see if any one of the steps causes the sign reversal. None should but they may. If they do, fix them. (while doing all this it may help to create "probes" on some of the wires to display their values).

This logic referred to above comes from your "requirement" that X has a range from 0 to 2000 and Y has a range from 0 to 360. Note that those numbers (0, 2000, 360) are ABSOLUTE numbers as far as the physical hardware is concerned. Yet within those absolute bounds you said you wanted to do relative positioning and not go outside those absolute bounds. The only way to do this is to use (your best guess of) the current absolute position for the axis and see whether or not the requested relative position change will cause the axis absolute position to go outside those bounds and if it will, coerce the requested relative position change value back far enough so the axis stays within bounds. This logic is trying to make that check and coercion if necessary. It may be doing it wrong. **

If the problem is not in the bound-checking logic, then use the same techniques as described above to follow what happens when you press the "make a relative move" button and see if you can see where a sign change might be happening.

I've really go to get back to my work now but I'll leave you with this. Down at the bottom of this forum page are several good links for people starting out with LabVIEW. You may want to take a look at them.

** Just an update. I had a couple of minutes this evening to take a look at this wrong-sign problem and it is exactly where I said it would be. Using the troubleshooting method I described above it took me all of two minutes to see where the problem was occuring and fix it. For the practical experience you need to see if you can find it as well in the same manner. And remember, once you find and fix the problem for one axis you'll need to take care of the other axis in a similar manner.