Jump to content

Sending a Character through Serial


zero-tolerance

Recommended Posts

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

You can bet on that, Now as I am starting to get a good idea around LV I am also starting to enjoy programming with LV. Thnx again for everything.

I also totally agree with Wmassey, thatr unless the effort has put in there is no result and no way I would be able to learn LV.

Believe me that I am trying day in and day out to understand how the LV works but I dont agree with my tutor at University saying that it is a very easy programm to work with. I really am finding the opposite.

Nevertheless I managed to spot the problem that I had with the "move relative" part, where it was only giving me the negative answer ( I ilustrated this below). The step by step procedure that you told me was very helpfull (even though it tokk me aound 1hour and 15 minute :P ). Would it be ok if I can ask for some more assistance i.e. to make some changes to the existing program. I DONT WANT FOR YOU OR ANYONE TO DO THE PROGRAM but just as you did earlier with the steps of finding that problem, and this way I can actually understand things better, and it will really be a big push for me towards learning and being more familiar about the LV program itself.

Once again, I really dont know how to repay you guys, specially "Wmassey", orko and the rest as you really gave me the best help there could ever be. My self I never used any forums before as I really never believed they could be much of help, but that is certenly going to change from now on, and I'll try and lend my experience to the others too. :worship:

Millions of thanks again.

post-4068-1140652738.jpg?width=400

post-4068-1140652766.jpg?width=400

Link to comment
  • Replies 56
  • Created
  • Last Reply

Top Posters In This Topic

Now as I am starting to get a good idea around LV I am also starting to enjoy programming with LV. Thnx again for everything.

I am relieved that you were able to find and fix the problem (you did remember to fix it for both axes didn't you?)

It's good that you are starting to get into this LabVIEW programming. It can be fun (or at least not boring).

Since you are new at this I have attached a PDF file that shows how I have the LabVIEW options on my machine setup. You may find it useful, or you may have already figured out a setup that works well for you, in which case you should stick with it.

I'm glad to have been some help to you. Feel free to pass it on.

Download File:post-2800-1140668131.pdf

Link to comment

Thnx for the reply.

I tried to add this second serial port in but Im not too sure If its going to actually work. I havent got a chance to try it till next week on the lab, as its closed for the half term at the University, but I just dont feel completely right, I mean I'm not too sure if I actually did it the right way or not. I took a print screen of what I have changed as well as the updated program.

I have also Copied the "Yak at McLennan.vi" and renamed it "Yak at McLennan Encoder.vi" and I placed it under the same SubVI's folder.

I'm not sure if that is enough, or if I need to do something too it.

Thanx again.

post-4068-1140740273.jpg?width=400

post-4068-1140740410.jpg?width=400

Download File:post-4068-1140740477.zip

Link to comment
Thnx for the reply.

I tried to add this second serial port in but Im not too sure If its going to actually work. I took a print screen of what I have changed as well as the updated program.

I have also Copied the "Yak at McLennan.vi" and renamed it "Yak at McLennan Encoder.vi" and I placed it under the same SubVI's folder.

First of all, you probably don't want to repost the entire system of VIs if all you changed was one of them. It's a waste of space on the LAVA server.

Second, I know nothing about the communication protocol or message format of your encoder readout device but I suspect that it ("Yak at McLennan Encoder.vi") will not work since you have turned off the "Enable Termination Character" function. With that turned off, the only way that the "VISA Read" will terminate is when the "Byte Count" number of bytes have been received (which is set to some high value like 100) or when a timeout occurs. The "Yak" vi's are only meant to work with messages that have some sort of termination character.

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.

If you built this hardware then you could modify the code it is running to include some sort of termination character couldn't you? It could be any character that doesn't otherwise show up in the message. A carriage return or a line feed character are the typical terminators but it could be anything (space, tab exclamation point, ...).

If you cannot change the code, then it becomes more difficult to correctly readout the device. You have to build the code so that it knows when it has a full/complete message or reading and not a random collection of numbers made up from the tail end of the preceding message and the beginning of a new message. For example,

1) if the axis was stopped and the encoder position was sitting at a value of 12345

2) the encoder device continually spits out the current reading over & over again

3) you have the VISA Read setup to terminate after 5 characters (Byte Count) are read in

4) then when you go do the VISA Read, depending on when it starts to listen to the serial link you might get any of these values returned:

12345, 23451, 34512, 45123, or 51234.

The situation becomes even more confused if the axis is moving and the numbers are changing and it becomes nearly impossible to deal with if there there are not a constant number of characters in each message.

If there is a fixed, known, constant delay between the encoder messages then you can play with timings of multiple VISA Reads to determine when you have one good reading but this is an inefficient way to spend your program's execution time.

As far as where to add the encoder position check/display into the main program, to help make that decision you need to get a good mental picture of how the program works. To that end, why don't you build a flowchart of the main program. Keep it high level. These are the nodes I'd suggest using in the chart:

Initialize System, Check Motor Status, Moving?, Disallow Timeout, Allow Timeout, Update Display, Adjust Parameter, Start Motion, Wait On Event ( containing Setup Change?, Timeout?, Move? Done?) and Shutdown.

FWIW, if you have access to Microsoft's VISIO software, it will do flowcharts. Pencil & paper work well too.

And on another subject, this probably will not do whatever you were trying to accomplish when you added it:

post-2800-1140794112.png?width=400

The "Response" buffer just contains whatever was last read in for any axis. If you want the position for a specific axis, then you need to pull it out of the "Axis Status" array (just below it in the picture, use the index array function {with the correct index for the axis you want} followed by a Unbundle by Name for "Current Position")

Link to comment

Hi there again, I wanted to ask if one of the below examples are any good for parallel connection. During my search I found out that VISA can also be used for parallel connection but when that is used the pins 11 and 12 need to be grounded externally (where in my case they can easily be done). There was another idea where the "in port" can also be used, but this time the registers address for the parallel port needs to be given (where in my case its 0378).

All that I need to do is use the parallel port as input, not as output as there is no need for me to writte anything out to the parallel port, but instead I need to check for three pins only i.e. pins 2, 3 and 4. and nothing else, infact all the other pins are empty, I only have a ground on pin 18 of my parallel port and thats it, I now need to read from pins 2, 3 and 4. These pins will usually be HIGH (5 V) but only when something happens to the external hardware depending on the condition one of the pins i.e. either pin 2, 3 or 4 will become logic LOW i.e. (0 V). When ever any of these pins of the parallel port is trigered low I need to send a function through the serial port (Which is allready set up). i.e. when pin 2, 3 or 4 of the parallel port becomes "0 V" or logic LOW then i need to send the command "01#st", as well as I just need to have three LED on the front pannel for three of these pins, depending on which pin is trigered LOW then that LED should light up, indicating of this change and automatically send the mentioned command. I really tried my best searching about this but looks like once again I need your help. If its possible to have something as simple as possible, i.e. there is no need for me to do any of the error checking or anything like that but only the above task. anthing would be approciated, thenx.

post-4068-1140929811.jpg?width=400

post-4068-1140929825.jpg?width=400

Link to comment

You are on your own as far as advice from me on using the parallel port - it's something that I have no experience with.

But, if you are still thinking of bringing in the two limit switches and the home switch through the parallel port instead on through the McLennan controller where they belong, let me urge you in the strongest possible terms DO NOT DO IT!

You can damage equipment or hurt people if you don't do this in the correct manner and what you proposed a few messages back is definitely the wrong way to wire in the limits! You will not "Increase your marks" if you either hurt someone or damage something.

What's really bad about what you are proposing is that it has a chance of working at least some of the time and that will give you a false sense of security. It cannot be relied upon to work all the time however and there is where the problem lies. What are you going to do when you have just given the motor a jog command and it has started running and your PC (or LabVIEW) crashes? It's been known to happen and they won't be the only things crashing in this example. The motion controller is a much more reliable device in this respect (and at least, if it crashes, it will stop stepping the motor).

The McLennan manual tells you how to hook up these switches to the controller and you need to follow those instructions. Later when the LabVIEW makes a request for axis status, the state of all three of these switches is already included in the data returned from the controller and you can use that for driving any front-panel indicators. DO NOT USE THE PARALLEL PORT FOR THIS PURPOSE!

Link to comment
You are on your own as far as advice from me on using the parallel port - it's something that I have no experience with.

But, if you are still thinking of bringing in the two limit switches and the home switch through the parallel port instead on through the McLennan controller where they belong, let me urge you in the strongest possible terms DO NOT DO IT!

You can damage equipment or hurt people if you don't do this in the correct manner and what you proposed a few messages back is definitely the wrong way to wire in the limits! You will not "Increase your marks" if you either hurt someone or damage something.

What's really bad about what you are proposing is that it has a chance of working at least some of the time and that will give you a false sense of security. It cannot be relied upon to work all the time however and there is where the problem lies. What are you going to do when you have just given the motor a jog command and it has started running and your PC (or LabVIEW) crashes? It's been known to happen and they won't be the only things crashing in this example. The motion controller is a much more reliable device in this respect (and at least, if it crashes, it will stop stepping the motor).

The McLennan manual tells you how to hook up these switches to the controller and you need to follow those instructions. Later when the LabVIEW makes a request for axis status, the state of all three of these switches is already included in the data returned from the controller and you can use that for driving any front-panel indicators. DO NOT USE THE PARALLEL PORT FOR THIS PURPOSE!

Greate advice Warren! I second your warnings with the strongest possible meaning. Motion Control is not something you can do insecure at all. After all a finger is lost way to easily and for bigger motion systems worse things can and have happened.

Rolf Kalbermatter

Link to comment

Sorry if I misled you all, but the limit switches are allready set up through the MClennan Controller and they work fine, when the motor goes to one of the ends it automatically stops. this is something that is covered with my hardware, so its not fully dependet just from the computer. Appart from that I have also included manual controll switches which move the motor manually to the left or right. but I was also thinking that because I have the limit switches in the hardware there are no indicators on when the limits are activated but instead it just stops the motor straight away, no matter what the motor was doing, as my hardware at that point completely cuts the power to the motor, and due to the weight ( they are at least 500 kg each) the motor stops completely, this method has also been adviced by my supervisor. But now I was thinking to stop the motor via the software i.e. through the user interface as when the limit switch is activated the motor moves for another 3 mm before my hardware kicks in to cut the power. So now i was thinking to stop the motor via user interface before the it reaches the 3 mm i.e. when the limit switch is activated then straight away i wanted to send the stop command without having to let my hardware take care of it, and if that fails than I have my hardware as the back up or as the finall emergancy stop. ou, and as for body harm there is no worries as the motors that i am controlling are actually in totally different room and a pass is required to enter that room, as there are other very delicate devices in the laboratory, and everytime i try to controll the motor I have to be on the other room but i can only see the motor via a see through glass when i move it.

Later when the LabVIEW makes a request for axis status, the state of all three of these switches is already included in the data returned from the controller and you can use that for driving any front-panel indicators.

How do you make these requests and how do you get the status of the limit switches. i.e. what command did you use for this

thanx for your concern

Link to comment
Sorry if I misled you all, but the limit switches are allready set up through the MClennan Controller and they work fine, when the motor goes to one of the ends it automatically stops. this is something that is covered with my hardware, so its not fully dependet just from the computer.

I'm glad to hear that.

Appart from that I have also included manual controll switches which move the motor manually to the left or right.
Do you know that this too can be accomplished through the LabVIEW? You have a Jog(+) & a Jog(-) pushbuttons ("Switch Until Released" action) and when a button first transitions to a pressed/down/on state you issue a jog command (the McLennan "CV" command) and, depending on which button was pushed, you set the sign of the argument to the command either positive or negative to set the direction. When the button is released then an axis stop command is sent.
but I was also thinking that because I have the limit switches in the hardware there are no indicators on when the limits are activated

I think you do have indicators in the LabVIEW already. See below.

but instead it just stops the motor straight away, no matter what the motor was doing, as my hardware at that point completely cuts the power to the motor, and due to the weight ( they are at least 500 kg each) the motor stops completely, this method has also been adviced by my supervisor.
You speak of your hardware "cuts the power" to the motor. Based on my reading of the McLennan manual, if you are using their hardware to handle the limits then it shouldn't just "cut the power."

From page 8 of the manual:

The method of stopping, on hitting a hard limit switch, may be selected, by the RL (ramped limits) command. If the ramped limits are OFF then hitting a hard limit will stop all step pulses immediately. If ramped limits are ON then the speed will be ramped down to the base speed (if above it) and then it will stop. Without ramping and if the speed is above the pull-in rate of the mechanism, the positional integrity may be lost. It should be noted that it is possible to decelerate a motor quicker with ramping and a suitable acceleration rate than with a dead stop. With either method, the limit switches should be positioned to allow the mechanism to decelerate to a stop before hitting a mechanical end stop. The limit switches should be mounted so that they are activated as the load passes them and will not be crushed if it overshoots.

So you can set it to either just stop stepping or else just decelerate to a stop but neither of these is "cutting the power" which I don't think you want to do with a stepper anyway because it's holding torque is greater with power applied than with power off.

You need to read about and figure out how to use the soft limits that are supported by your McLennan controller. Search the PDF file on that term. This will require that the system know its correct absolute position so you will have to get the home switch operating (or the datum switch as McLennan calls it). If you want to see the status of the DATUM switch using the LabVIEW, you will need to use the "RP" command.

But now I was thinking to stop the motor via the software i.e. through the user interface as when the limit switch is activated the motor moves for another 3 mm before my hardware kicks in to cut the power. So now i was thinking to stop the motor via user interface before the it reaches the 3 mm i.e. when the limit switch is activated then straight away i wanted to send the stop command without having to let my hardware take care of it, and if that fails than I have my hardware as the back up or as the finall emergancy stop.
Again this could be handled by the soft limits. If you want to add an additional set of early-warning limit switches to the system and have those tell the software to stop the motion you could indeed do that. But, if it were me, I'd use a couple of the "Read Port" inputs on the McLennan controller to get those signals into the controller which could, in turn, make them available to the LabVIEW code (again through the RP command). It may not be a good idea to hook signals from an industrial control system directly up to the parallel port of a PC. Some of that industrial-strength noise may fry your motherboard.
How do you make these requests and how do you get the status of the limit switches. i.e. what command did you use for this

Like I said, you've already got this indication:

post-2800-1140969711.png?width=400

And this is how you would access the booleans within the main program:

post-2800-1140969724.png?width=400

And, FWIW, according to the error messages (page 77 of the manual) that the McLennan will return in response to commands, it will even tell you when you are at a limit.

Link to comment

Dear Wmassey

I have managed to put together the "probably final" program that I am using in LV, and I have attached it at the end. I know that its not even 5 % to what you have shown me but this at least I can "FULLY" explain on my report (which is required) hence I know how it "FULLY WORKS".

The reason why I am not using your software is ONLY because I need to explain all of that on my report i.e. what each part of it does and how it fully works, where at this stage I am not capable of doing, as that program really is in a COMPLETELY different level of knowledge to where I am at the moment.

When I first started to ask for help in this forum it was my second day that I had ever touched LV, actually I never even heard of such program untill my supervisor mentioned it, as my first intentions were to use the "STONE AGE Hyper Terminal" by manualy entering the commands, but then LV was introduced to me.

Please dont take this the wrong way by thinking that you spent all that time helping me and at the end it was rubish, as I really REALLY couldn't have done this without your help.

Untill now I managed to understand LV to its basics capabilities. I know I could have probably done and understand much more than now but probably I am not as bright and clever as some other people might be.

So far I only used the While loops and Case structures as these are the only things that I feel confortable working with at the moment.

Now I at least learned how to built and use SubVI's that you had done, as well as the main concept of how the data flows in LV.

I WOULD LIKE TO REALLY APOLOGISE IF I HAD LET YOU DOWN SO FAR IN ANY WAY, because despite your endless efforts on trying to help me understand as well as trying to help me with this project I only managed to go this far.

But just to let you know that it does not have to be an advanced User Interface (which would be through LV), as this language was never taught in the University, and they dont axpect a professionally built LV program.

My self I am studying Electronic Engineering and I'm on my Final year. I can surely say that anything to do with electronics i.e. Microprocessors, Microcontrollers etc I am confident working with i.e. programming them etc, I will later this week post some images of what I have been working so far and the hardware in which I have built. The software that I have a high level of knowledge is the Assembly Language, which is used only on electronics for Programming Chips, which would normally be via EPROMS or Non-voletile RAMs.

The reason that I posted this last section is just to show that I really am not someone who is dumb on everything, because I am not really feeling confortable on always asking for your help as I am always taking a lot of time from your own work. But as this time I have hit the rock bottom with LV I had no other choice, So I hope you wont be to angry with me.

If its ok by you I have probably the last questions below that I might be asking about this project .

1) I tried implementing that "jug" command i.e. the CV command by using the toggle switch, but It keeps sending the "ST" command all the time when the switch is not pressed and the "CV" command everytime when the switch is pressed. What I need is something that when I press it it will only send the "CV" command once and When I release it, it will only send the "st" command once, so that the user can go back and use the "MR" as well as other features afterwards. I have ilustrated in the picture below about this matter. The reason I know this is that I am also running the PortMon program at home, where I am contstantly monitoring the Serial port and now when I run the LV program I can see that it constantly sends the commands.

I also know that why this is happening, becuase I dont think I can use Case structure or putting this part of the software inside the While loop because it keeps constantly execute theses commands i.e. when the Case Structure is true, it will constantly send CV command and when Case structure is False i.e. when the switch is off it will constantly send the "ST" command.

2) I am reading two serial ports i.e. one serial port is reading and writing the messages to the McLennan device and the other serial port is ONLY reading from my microcontroller. What I want is when I read from my Microcontroller (which will always be a Five digit number and onw decimal point i.e. I will only read in the form of "256.78" this is the type of data tha I will always be reading from my Microcontroller) I want to display this number fully in One small box, i.e. same box size as the one "Number of Steps Going To The Motor" which can be seen on my front pannel. I am reading quite fast, i.e. at a rate of 10 miliseconds,so I just need to keep displaying the new number that comes through ( this would be when the motor is in motion ) and when the motor stops the last value that is read by the serial port should be held at least untill the new number comes in to replace the old one, and so on. This problem however is for both serial ports, but the solution I would assume would be the same, as all I am trieing to do is diplay.

3) And finally I am trieing to make a Slideing Bar (which is shown in the front pannel) and instead of connecting that to the values that the user inputs I would like to connect that to the numbers i.e. the values that are comming through the serial port i.e. if I recieve 34.56 through the serial port of the Microcontroller then the slide bar should move to the 34.56 place. Dont worrie about the limits of the slide bar as I can easily change them on my side. The reason I am not able to do this is that anything comming out of the serial seems to be a String, whereas the slide bar accepts a different ype of value, and I am having trouble converting that simple thing.

If it takes too long to implement your idea on my program than just a prototype of what you would do would be great.

thnx again.

Download File:post-4068-1140986484.zip

post-4068-1140986508.jpg?width=400

Link to comment

I think it's great that you have put together something of your own, that you can understand, for accomplishing what you need to get done!

I certainly do not feel let down (not that you had any responsibility to "keep me up" in the first place).

I'm glad that I have helped you learn a bit about LabVIEW if nothing else. I've done the EE thing (and for that matter the ME thing as well) and my son is in his sophomore year at the University of California (Berkeley) doing the EE thing as well so I know what you are going through and I have no doubt that you are a very intelligent person. I never meant to imply otherwise, if I did so.

As to your questions:

1) For the "jog" function - you only want to send out a command when the state of the button TRANSITIONS from low to high or from high to low. While the button state is low or is high you don't want to send anything. So you need to know the prior state of the button and compare it to the current state and when there is a difference then you send out a single command dictated by the current button state. (BTW, your CV command may need a speed argument).

2) This would have been much easier if your microcontroller used a string terminator character after each message but you are probably getting as tired of hearing that from me as I am saying it. Anyway if the number format in the message is always exactly like you specified then you can search the collection of bytes coming in from the VISA read function for something that looks like 3 numeric digits a decimal point and 2 more digits and when that string is found, pull it out and use it.

3) This will be easy to do once you get #2 above right. The "scan from string" function will do all that you need if you feed it good values.

See the attached top-level VI.

And I would very much like to see any pictures you might have of your project!

Download File:post-2800-1141002358.zip

Link to comment
2) This would have been much easier if your microcontroller used a string terminator character after each message but you are probably getting as tired of hearing that from me as I am saying it. Anyway if the number format in the message is always exactly like you specified then you can search the collection of bytes coming in from the VISA read function for something that looks like 3 numeric digits a decimal point and 2 more digits and when that string is found, pull it out and use it.

ou I am very sorry to have forgotten about this, I have actually implemented the string terminator character after each message. I am sending a "Line feed" before every message and terminating it with a carrige return (PC's Enter key) character after every message.

Im sure this would make things much simpler.

I have made some changes to the program you have given me, would tha be the final solution to what I need.

Sorry about this.

Download File:post-4068-1141006909.vi

Link to comment
I have actually implemented the string terminator character after each message. I am sending a "Line feed" before every message and terminating it with a carrige return (PC's Enter key) character after every message.

I'm glad to hear that you were able to make this change. It makes everything so much more deterministic. You were correct in the parts you removed from the top-level VI but you also needed to enable the terminate-on-character option for the VISA. See attached VI for the corrections. I've also fixed it so that if you do get errors you can see them.

Download File:post-2800-1141018911.zip

Link to comment

Hello again, sorry for not posting this earlier, its just that I was too busy writing up my report.

Below are some pictures that I took the other day on my lab, it shows the place where I am working at as well as the as well as the motor that my project is based on. I also included some pictures of my hardware that I had to built so that I could read, calculate and send back the angle to another machine for display.

If you are interested I can also give a brief introduction of how the hardware is built, components that are included etc.

-------------------some bad news----------------------

A few days ago I tried to run the whole project as it is supposed to work, i.e. connecting the motor to the PC via serial, connecting my hardware to the PC via serial and connecting the hardware with the motor together.

Everything went smoothly up to the part where I have to read the ngle comming from my hardware to the PC.

Apparantly I cannot comunicate with my hardware at the same time as I comunicate with the motor.

I can controll the motor, read the messages back from the motor and everything else, but what I cannot do is read any message that comes through my hardware.

I know that the hardware is correct as I cn read the messages comming from the hardware with normal basic serial read and write examples that are in the LV section. and also I can read my hardware when I swap the COM ports with the motors but I cannot read anything from my hardware when I connect both serials at the same time, and try to read from them. I am not sure if LV supports this. If I connect anything to the first serial communication where the motor is connected through then I can read and write correctly but if I connect anything to the second serial that I had done in the LV then nothing comes up.

Is it the way that the LV executes the program and the second serial cannot be properly working? but then again when I check both ports through the PORTMON prgram I can see that COM 2 is properly initialized depending on the parameters I am inputing in LV program for serial, or is it to the way that I programmed it, i.e. i didnt include a write VISA on the second serial because all im trying to do is read through that serial.

Have you got two devices that you could possibly connect to both of the serials at the same time and talk to them or more importently to try and just read anything through them, so that you cna see exacly what is happening, because for the past two days I tried everything and I cannot get this working.

---------------- end of problem------------------------------------------------------

thanks WMassey and I hope you can help me with these last problems so that I can patch up and finish this project.

Download File:post-4068-1141408917.zip

Link to comment

LabVIEW can read from 2 serial ports just fine. I've done 6 at the same time so far and I see no reason why it couldn't be 60.

It wasn't clear from your message but have you ever gotten the reading of messages from COM2 to work?

You do know that the way you have your main WHILE loop designed that there are two tasks that both have to complete before one itteration of the loop finishes and the next itteration of the loop starts. So it may be that something going on in the top half (COM1) of the loop could be hanging the loop causing the bottom half (COM2) to never get a chance read more than once.

You might want to split this one loop into two independent loops (at least for the sake of testing). After doing that you could even drop the bottom loop into its own VI (drag all of the bottom loop's code from its block diagram onto a blank VI's empty block diagram) and that would give you an independent copy of the code that should run and display whatever appears at your COM2 port. You could then do likewise for the top loop (get it into its own VI) and you should also be able to run that one indepently against COM1 and the motion controller. If both VI's run indepently then you should be able to make them run when combined.

two loops:

post-2800-1141415014.png?width=400

two VIs:

post-2800-1141415026.png?width=400

Link to comment
  • 2 weeks later...

up to now I have been trying to compile and write the report, sorry for not informing about the situation around this labview program that i was given a troumendus help from this forum (specially Wmassey).

anyway, i am back for some last bits and bobs. I have been trying to store a value that I get from the hardware i.e. the angle.

So, when I read an angle from the serial port (lets say 234.57 degrees) i want the labview to remember this value and store it somewhere (like a memory or something) and then close the LV aplication (or even shut down the computer) and when I open the aplication again i.e. the LV program then this value of the angle i.e. 234.57 will still be there, and now when I run the program and read the second value of the angle through the serial i.e. 54.67 then it will just add up to the last one which was 234.57, so now the actual angle will become 234.57+54.67=289.24 degrees, and then when I close the program (or switch off the computer) then this new value is memorised.

I tried looking at the shift registers which seems to act like some sort of memory, which remembers the last values but I cant get it to work the way I want to.

has LV even got this capability (which I really think it does), if so can anyone show me a way around it.

The program that I am using is uploaded previously in this post but since there are so many different ones that are posted then I am more then happy to upload my newest version again (I just don't want to take so much memory space by posting by programs :D ).

Thankyou in advanced.

Thankyou in advanced.

Link to comment

You will need to save the data to disk to retain it's value after exiting the program or shutting down the PC.

Upon program start, it can open the file, extract the value and use it to add to the new value.

Read to Spreadsheet File, Write to Spreadsheet File come to mind. You could also write and read value into 'keys' using the Write and Read Key. Search in Find Examples for Spreadsheet and Configuration to get you started.

Link to comment
I have been trying to store a value that I get from the hardware i.e. the angle. So, when I read an angle from the serial port (lets say 234.57 degrees) i want the labview to remember this value and store it somewhere (like a memory or something) and then close the LV aplication (or even shut down the computer) and when I open the aplication again i.e. the LV program then this value of the angle i.e. 234.57 will still be there, and now when I run the program and read the second value of the angle through the serial i.e. 54.67 then it will just add up to the last one which was 234.57, so now the actual angle will become 234.57+54.67=289.24 degrees, and then when I close the program (or switch off the computer) then this new value is memorised.

As was pointed out, you need to save it to disk.

I've put together a kit (LV v7.1.1) for you. Some assembly is required. Instructions are included in the zip file.

post-2800-1142470238.png?width=400

Download File:post-2800-1142539704.zip

Link to comment
Sorry Wmassey, you referred to a ZIP file for instructions, but the uploaded file is the Vi file only. Is this what you meant?

Oops! You are right. I grabbed the VI instead of the ZIP file. I've corrected the post. There's a PDF file included in the zip file.

Link to comment

Sorry again, but I think im kind of stuck at the moment.

Lets say that when the user switches on all the devices i.e. the motor, PC etc. At that time the motor would be at 0 degrees. Now, when the user puts in an agnle, lets say 25.00 degrees, then the motor moves, but at that time I also need for the command "01OC" to be sent automatically. what this command does is interigate the PM341 device (which is linked to the motor) and report back with the position of the motor that I am moving. i.e. during the time when the motor is moving from 0 degrees to 25 degrees I am constantly sending this "01OC" command to check its positions. so the user can see the angle on the screen increasing from 0 to 25. when now the angle goes to 25 degrees I need to stop sending this comman, but again, only when the users Desired angle is the same as the actual angle comming from the PM341 device.

I tried making a FOR loop for this purpose by checking if the users desired angle and the actual angle is NOT EQUAL to zero, and if its not true than a boolean TRUE would constantly be sent to another CASE STRUCTURE where this "01OC" command is send from. But everytime I am trying to linke this I cant because it keeps giving me a message saying that "These wires form a cycle, making two parts of the diagram interdependent, so each must wait for an input from the other and neither can execute.". I understand what its trying to say, so now I thought of using shift registers instead, i.e. by sending the actual angle comming from the PM341 device to the shift register and then link the other end to the For loop, as shown. In this case it does not give me a error message, but it doesnt work the way I want it to. i.e. when I type in an angle I do get the same angle but the commands keeps being sent.

Thankyou.

post-4068-1142724973.jpg?width=400

post-4068-1142724997.jpg?width=400

post-4068-1142725008.jpg?width=400

Link to comment

At the moment I cannot spend much time trying to figure out what you are trying to say here but I do have a few of observations:

  1. You talk about "FOR" loops when I think you are referring to "WHILE" loops.
    You really need to get your terminology straight because getting it wrong only makes it harder for us to help you.
    If you are not sure which is which, right-click on the loop and select "Show Label"
  2. In the third image you posted, down in the lower-left corner of the circled area, you have a Decimal String to Number function with no string wired to its input so you will only get the position value of "0" out of it.
  3. A shift register (or you could also use a "feedback node") would be the correct way to retain the position value from one cycle of the loop until the next.
  4. You really do need to learn to you the spell checker that is available when posting to this forum (and I mean this in the kindest way).

Link to comment

I really really apologise for making most if not all of my posts long. I just wanted to explain my needs as explicit and as detailed as possible.

  1. You talk about "FOR" loops when I think you are referring to "WHILE" loops.
    You really need to get your terminology straight because getting it wrong only makes it harder for us to help you.
    If you are not sure which is which, right-click on the loop and select "Show Label"
For this I actually meant FOR loop. These FOR loops are situated on the top right hand corner of the first image above. The bottom FOR loop is for motor X and the top FOR loop is for motor Y.

In the third image you posted, down in the lower-left corner of the circled area, you have a Decimal String to Number function with no string wired to its input so you will only get the position value of "0" out of it.
You are correct about this but I was actually making this post while I was also doing the program, and when I took the screenshot at that time the "Decimal to String" as well as many other functions were not wired at that time.
Sorry for creating this confusion.

A shift register (or you could also use a "feedback node") would be the correct way to retain the position value from one cycle of the loop until the next.
I tried doing it this way. The three images above show the way that I have connected them, but don't pay attention to the other functions that are outside the circled area as at that time I was trying different methods and some of the functions look unwired, but when I tested it everything was wired correctly. I only posted the way that I connected the FINAL result coming out of the serial and connecting that to the Shift Register and putting that through a FOR loop.

You really do need to learn to you the spell checker that is available when posting to this forum (and I mean this in the kindest way).

I truly agree and from now on I will take your advice, but I would like to apologise in advanced for any parts of the wording that don't make sense, as English is my third language (even though that's not an excuse for me).

As an addition to this post I am Uploading my up-to-date LV program that I made, but this one hasn't got the feature of sending the "OC" command whenever it's needed, but instead I just made it so that the "OC" command is continuesly sent to the motor (which really its not the preferred way at all). This program works fully except this last part. There might also be some unused VI's inside the SubVI's folder but I haven't cleaned it out yet as I am still modifying bits and bobs on it.

Thanyou

Download File:post-4068-1142737048.zip

Link to comment
I am Uploading my up-to-date LV program that I made, but this one hasn't got the feature of sending the "OC" command whenever it's needed, but instead I just made it so that the "OC" command is continuesly sent to the motor (which really its not the preferred way at all). This program works fully except this last part.
I'm not sure that it's necessarily bad for a motion control program to periodically request the position of its motors, even in an idle state, but if you would rather not, then it can be made so that it will do as you wanted - i.e., only ask when it thinks that there is a difference between the requested and current position. See how I have modified your main VI. I think it will do as you wanted.

You will also note that I have pointed out some unused or nonsense bits of code and cleaned it up a bit cosmetically. It's hard enough to follow someone else's thinking even if it is NOT spread across multiple screen widths with hidden wires and wires that do not line up or otherwise zig-zag across the diagram. Make it easy on those who might help you by not making them work to read your code.

Keep it neat.

Download File:post-2800-1142780488.zip

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.