Coding Technique and Motion Controller

[bono02]

Hi all,

I am new to this forum, I hope I do not post on a wrong category. As a newbie in LabVIEW, I have several questions:

1. What is the best or most comfortable coding technique in LabView, I heard there are several choices like FSM, Producer Consumer, State Chart, so on? I am confused which one I should choose. FYI, I am going to control using motion controller PXI 7358 4 stepper motors, 1 servo, F/T Sensor and 1 BLDC maxon motor.

2. What do you usually do when designing a huge program (single programmer?), do you design using UML or something similar to that? Choosing wrong coding technique -for me- means that unreadable code, and uncomfortable huge program layout in the screen

3. Why there is no zoom in/out option in LabVIEW? Why the LabVIEW designers do not provide that?

4. Any body here is using PXI 735x? I searched in this forum, I found only several topics regarding this. I hope we could share knowledge and idea about the motion controller.

Your response is really appreciated.

Bondhan

~Another C programmer who move to LabVIEW

http://bono02.wordpress.com/

[mross]

QUOTE(bono02 @ Nov 11 2007, 10:57 PM)

Hi all,

I am new to this forum, I hope I do not post on a wrong category. As a newbie in LabVIEW, I have several questions:

1. What is the best or most comfortable coding technique in LabView, I heard there are several choices like FSM, Producer Consumer, State Chart, so on? I am confused which one I should choose. FYI, I am going to control using motion controller PXI 7358 4 stepper motors, 1 servo, F/T Sensor and 1 BLDC maxon motor.

2. What do you usually do when designing a huge program (single programmer?), do you design using UML or something similar to that? Choosing wrong coding technique -for me- means that unreadable code, and uncomfortable huge program layout in the screen sad.gif

3. Why there is no zoom in/out option in LabVIEW? Why the LabVIEW designers do not provide that?

4. Any body here is using PXI 735x? I searched in this forum, I found only several topics regarding this. I hope we could share knowledge and idea about the motion controller.

Your response is really appreciated.

Bondhan

~Another C programmer who move to LabVIEW

http://bono02.wordpress.com/

Greetings,

1)These are architectures designed to fulfill specific needs. That is not an exhuastive list either, there are plenty more options. It is probably too soon for you to be worrying about them. See item 2. You have not provided enough information about the top level funtion for anyone to give you a sensible answer. I advocate that if you don't know what you are doing, then explain the basic needs to be met by the program, and what decisions you neeed to make based on the results of the program. If you assume too much about how the task should be done, you may get answers for the question, but maybe not the best overall solutions.

For example, say it like this:

I need to position the following components so they can be assmbled together and fastened by the following techniques, then I must verify that the assembled form is within the following specifications. I will need to verify dimensional compliance to pass or reject the assembly, and I need to activate the assembly, acquire voltage data from the following transducers operting at the following levels, and current data from this one. The fasted acquisitions will be done at the following rates. Then I must analyze this data in the following manner to provide the following dynamic responses for immediate graphical display and review by a human. The human can react in the following ways to the graphical display. Two responses can be evaluated by the program without human review and the following actions initiated based on these responses. The data must be recorded in such and such a form for record keeping only. The front panel must provide the following controls and indicators for user interaction.

Say it like that and you will get higher quality answers.

Based on your comments I would say use the producer consumer becasue it is very flexilble, very orderly, and with modifications allows for human interaction, and I just like the P/C architecture and am familiar with it. Since I really don't know what you are trying to do and there could very well be better ways to do it. Whether or not you are storing the data and the size and format of that data are very important. How fast you are acquiring data or issuing commands is very important. Do the motors require active control? Will they just follw a script? Whenever there is motion you have safety concers to deal with.

2) This is how I would proceed. You must eat the elephant one bite at a time. Regardless how you package the various functions, you need to get these functions to work first. The control of the motors can be programed without the use of the top level architecture. Make smaller Vi's to become sub-Vi's for the top level later. Get your hands dirty with the details immediately. Pick a simple task and learn to do it. Pick another and do it, repeat. Expalin in detail small parts of what you need to do and ask for help. Read the forums at LAVA, infoLabVIEW and at ni.com.

3) You may want to change your display resolution if you have trouble reading the code. However I use very high resolution to get as much onscreen as possible. I am near sighted so it is not a problem for me. You can't zoom, but if you learn to develop the code using subVI's drilling into those is equivalent to zooming. You will become accustomed to it and you will come to see that it is not not a hardship. Windows does have a magnifier, maybe you will like that (doubtful).

4) no

Mike

[jdunham]

QUOTE(bono02 @ Nov 11 2007, 06:57 PM)

~Another C programmer who move to LabVIEW

You mean there's another one somewhere?

Anyway, Welcome to LabVIEW!

Here are my opinions, but I can guarantee they are not universally shared.

I hate state machines. Sometimes they are necessary, but most of the time they are not.

I do like a producer-consumer architecture for handling events. Events, UI or programmatic, can happen at any time, and you need to handle them promptly (less than 1/4 sec) so that your user feedback is snappy. However the part of your code which actually gets stuff done is often slow (more than 1 sec, often way more), so you need to let those operations run their course , undisturbed, in some kind of dataflow VI.

A corollary to this is to keep all of your user interfaces out of the operational code. Each VI gives you a user interface (awesome for testing) but you should resist the temptation to handle user interface needs with those VIs which are actually operating your hardware. Use your producer-consumer architecture to pass all the messages between those two worlds.

I like to use notifiers to send progress updates and results back from the operational code to the presentation layer. However if you are brand-new to LabVIEW, feel free to ignore all of that and show your results right on the operational VIs.

I don't use UML, I don't design on paper first, and I don't start by roughing out the GUI. Those are worthy techniques, but I like to do a bottom-up design. Code up all of your functionality one VI at a time, and stick to one piece of I/O at a time. If you need to read and write from files, write a VI for each of those. If your motion control moves in a straight line, write a VI to do that and one to monitor your motion status until it is complete. If you are looking for the limit switch, write a VI to detect that, and then another one to wait for the limit switch with a timeout function. Then put those together for whatever complex motion/measurement function you are trying to achieve. If you use the RS232 port, make a VI for each message you send and including a check for errors or return messages in that VI.

When you are all finished, you will have a much better understanding of what user interface you will need to set your tasks in motion, monitor the progress, and display the results. Then you can build the GUI and figure out what you need to add the operational VIs to get the information back and forth.

If you do all of this, your VIs should never get so big and unwieldy (though we've all been there), and you shouldn't need to zoom in or out.

As a C programmer, you have one file for each module, but remember, LabVIEW is one file per function, which is one layer down. You have to resist the temptation to stuff lots of functionality into each VI, and don't be put off by having to make an icon and a terminal pane for each function. It just doesn't take that long. Don't let any of the diagrams get too big or to have too many structures: While, For, Case, Sequence, etc. If you have more than 3 structures in a VI, you should think about why you are trying to do so much and consider making each structure the basis of a new VI.

If you are doing motion control and anything else interesting, and following my advice, you should end up with between 20 and 100 VIs. Keep them organized and give them all sensible names so you can find them.

OK, I'm done for now. Good luck!

Jason Dunham

[bono02]

Hi Jason,QUOTE

You mean there's another one somewhere?

Yes, there is. I read one thread in this forum, and he was writing about his code which using local variable and getting bigger and bigger QUOTE

I hate state machines. Sometimes they are necessary, but most of the time they are not.I do like a producer-consumer architecture for handling events. Events, UI or programmatic, can happen at any time, and you need to handle them promptly (less than 1/4 sec) so that your user feedback is snappy. However the part of your code which actually gets stuff done is often slow (more than 1 sec, often way more), so you need to let those operations run their course , undisturbed, in some kind of dataflow VI.

Can you explain more about this? I am planning to move to LabVIEW real-time, it said that the loop can provide to 1us. I don't have the RT now, maybe this week we're buying. Anyway, can you give me more literature about producer consumer architecture?QUOTE

I like to use notifiers to send progress updates and results back from the operational code to the presentation layer. However if you are brand-new to LabVIEW, feel free to ignore all of that and show your results right on the operational VIs.

Did you create a user event for passing message from both layers? What do you think about the performance?QUOTE

I don't use UML, I don't design on paper first, and I don't start by roughing out the GUI. Those are worthy techniques, but I like to do a bottom-up design. Code up all of your functionality one VI at a time, and stick to one piece of I/O at a time. If you need to read and write from files, write a VI for each of those. If your motion control moves in a straight line, write a VI to do that and one to monitor your motion status until it is complete. If you are looking for the limit switch, write a VI to detect that, and then another one to wait for the limit switch with a timeout function. Then put those together for whatever complex motion/measurement function you are trying to achieve. If you use the RS232 port, make a VI for each message you send and including a check for errors or return messages in that VI.

I learned from s/w engineering lecture, design is the most important part! I agree with this, but I have to race with the small time that I have. I am also not used to design everything in detail, just small chunk of algorithm, I usually write down first on paper, it helps me to write the code faster. But, I used to do same things like you, do all the interface with the hardware, and then coming to the higher level. I did that when I wrote a program for my mobile robot in undergraduate. My major was electrical engineer, so I have to code everything which connects to the hardware, small pieces of code. The computer science student will use that functions to create higher level code (like AI).QUOTE

As a C programmer, you have one file for each module, but remember, LabVIEW is one file per function, which is one layer down. You have to resist the temptation to stuff lots of functionality into each VI, and don't be put off by having to make an icon and a terminal pane for each function. It just doesn't take that long. Don't let any of the diagrams get too big or to have too many structures: While, For, Case, Sequence, etc. If you have more than 3 structures in a VI, you should think about why you are trying to do so much and consider making each structure the basis of a new VI. If you are doing motion control and anything else interesting, and following my advice, you should end up with between 20 and 100 VIs. Keep them organized and give them all sensible names so you can find them.

Ok, here we also have NI-Elvis. Not me is using it, but my friend. He's teaching undergraduate students. He told me that Elvis is too slow, too many top-level VI which slow the flow of the program. From your experience, what is the maximum level for a sub-VI should be?QUOTE

OK, I'm done for now. Good luck!Jason Dunham

Thank you Jason. Bondhan Novandy~Finding more literature of Prod/Cons in GoogleQUOTE(mross @ Nov 12 2007, 02:30 PM)

Greetings,Mike

Thank you for your reply Mike, 1 & 2) I mentioned about the actuators (stepper, servo and BLDC) just to show that I am going to design a quite big program, which needs precise control. Today, I managed to control the stepper motor (linear-actuator) with potentiometer feedback (separately though). I'd love to solve a problem by my own, but when I am stuck I will definitely go to forum and ask questions. This is what I have done, I have read the tutorial/webcast, ebook about FSM, even this mentioned that it is the best solution rather than using UML design (as far as I understand). I have tried the LV FSM toolkit, but for me I don't like it, I can not read the program clearly (maybe because it is using stacked sequence).I am afraid that once I code, a single small changes will ruin everything. In C it was easy, you can insert any code in any line you want, but in LabView I feel it is a little bit difficult. Thank you for your suggestion, I will try to use the producer/consumer coding technique smile.gif 3) Thank, I am using two monitors now thumbup1.gif , though I connect to the PXI controller using remote desktop! But still zoom in/out function I think is more comfortable, hehe.. 4) Ok. Thx.Note:Why my reply always ending up and merge with my reply to Jason?

[Norm Kirchner]

bono, depending on what your cost constraints are, and since time is short, and since you're new to LV, and since you're going to be getting into Real-Time hardware. I would strongly recommend finding an alliance partner in your area to help you get started on this. To give you a framework, a background and some idea how to properly code this up.

RT is not a simple task to program properly, especially with the motion control, and w/ the expectation of accuracy and precision. I don't know how much you figured you could learn and implement in a short time, but it looks like you might be over your head.

Your project seems really interesting and my true intent is to help you succeed, not be mean.

Time to call in the Marines.

[mross]

Here is an example of an even driven, enum queued, producer consumer that I put together for someone else. It is a basic example that shows 4 parallel loops fired by user events or running automatically.

http://forums.lavag.org/index.php?act=atta...ost&id=7435

This is a good example showing the power of dataflow programming. In the 4 consumer loops you could put what ever function you need and it will run uneffected by the other loops. One note, I ususally have an Initialize and Shutdown case in each parallel loop, and a case to Wait for User Input. In the example the Manual case is equivalent to Wait for User Input. Initialization can be for runnig for finding home positions, performing start up self self checks, and so on. I may strip this VI down and make a template of it for my own use.

One big difference between C and LabVIEW is dataflow. I am not sure from reading your questions and comments if you have the essence of dataflow. Intuitively you will opererate much differently when you a have incorporated dataflow into you thinking. When you talked about being able to insert a line of code anywhere, and that you couldn't do that with labview, it was a red flag for me that we could be talking past each other somehow.

I sometimes sketch out what I am trying to do on paper. A flow chart is usually all I need to get going in an organised way. My comment about starting with the details is partly becasue I don't think you are ready for the big picture yet. It will be more efficient if you run into walls doing simple tasks first.

Jason is exaclty right about not avoiding the connector pane and bringing together bunches small Vi's rather than writing it all in one big blob of code (which would definitely benefit from a zoom function). I used to be addicted to the Birdseye View VI, but now NI has given us the Navigation window (View/Navigation Window 0 or Alt V , N or Ctrl-Shft-N) You will like this. I find that when I have a big monitor I don't use the Navigation Window and I had fortgotten about it until just now. At any rate your request for a zoom function is a warning to me that you aren't really into the dataflow mindset and you haven't learned the value of creating sub-VI's.

If you use the bottom up approach you will be able to do useful coding, and learn enough to get the big picture right soon enough. Also a bunch of small VI's are easier to debug as you can test the function completely removed from the larger top level vi. There will be some things that seem inefficient compared to C, but I think you will quickly appreaciate the de-emphasis on syntax ;-)

I don't use RT, no advise there.

You were talking about time constraints. Don't underestimate how long it will take to learn this. Fortunately, it is fun.

LabVIEW really lends it self to bottom up programming. Using MAX you go in and get the hardware functioning first, then you can have some confidence that the debugging later on is concerned with software only.

With LabVIEW you do not have to wait at all before runing you hardware. I do hope you have introduced yourself to MAX (Measurement and Automation eXplorer). With this you get the hardware operating; later when coding since you are certain the hardware is up and running correctly, you can quickly make functioning Sub-VIs to use that hardware. Other subVi's to analyze data can then then be developed with the exact data and format so you aren't wasting time working with fictitious data imagined in the planning phases. A big time saver.

There is no maximum level of sub VIs as far as I know, if there is it must be very deep. The Block Diagram is just a developer interface layer and the compliation flattens this out and optimizes for you to a great extent. The things that make VI's slow are outlined in a number of places online. It makes interesting reading, but save it for later. Here are two things to avoid. Putting in front panel indicators (especially large array indicators, and clusters) in for and while loops that run without any pausing, and forcing LV to create many copies of large arrays are most common mistakes. Everytime you put a wire on a structure border you are creating a copy. If you can initialize arrays to be used in a loop before the loop runs that is good. If the array size is ambiguous then LV must remain prepared to supersize it.

Avoid Global Variables for a while. Be careful with Local Variables, don't go crazy with them. Shift registers are your friends. Property Nodes are slower than Locals.

Mike

PS. If you hit Add Reply you will complete the posting a be required to start anew. I can only assume that you did not do this.

[jdunham]

QUOTE(bono02 @ Nov 12 2007, 01:26 AM)

Can you explain more about this? I am planning to move to LabVIEW real-time, it said that the loop can provide to 1us. I don't have the RT now, maybe this week we're buying. Anyway, can you give me more literature about producer consumer architecture?

SubVI calls should take much less than a microsecond. They are very efficient. Do NOT use that as an excuse to let your VIs do too much. Your loops will be governed by your I/O speed, not your diagram code, unless you do bad things with memory management (changing/building arrays in a fast loop), and even then you might get away with it.

With a motion control system, your moves will probably take 0.5 - 60 seconds. If it is on the long side, you will need to be able to cancel the motion. The old fashioned way to do it was to make it a state machine, looping 10Hz or so, and check your stop condition, all of your GUI, and the state of your I/O. This VI would get very big and hard to debug, and would have to run at a fixed rate to handle everything in your system, often resulting in some performance compromises.

What I am suggesting is that you write a very simple VI to start it, and another simple VI to poll for completion, checking the I/O and also a notifier from your GUI (the "cancel motion" notifier), and any other termination conditions you need. After it works, do the next one, and then when all those are done, make your top-level application.

Make sure you understand you 1us requirement. It is probably impossible to write a pc-based application with reliable 1-100us deterministic closed-loop performance. RT will help, but your I/O calls will still be slower than that (though NI has been working on this since I last tried), and so you won't have much time for processing. In motion control, your physical processes (motion stage inertia etc) are usually slower than this, so I don't understand what you need. If you are measuring signals, you can use NI hardware-timed acquisition which is much faster, but only process the results at 100Hz or so and then there would probably be no need for an RT system. Without more info about your application I just couldn't say any more.

QUOTE(bono02 @ Nov 12 2007, 01:26 AM)

Did you create a user event for passing message from both layers? What do you think about the performance?I learned from s/w engineering lecture, design is the most important part! I agree with this, but I have to race with the small time that I have. I am also not used to design everything in detail, just small chunk of algorithm, I usually write down first on paper, it helps me to write the code faster.

Well, certainly do what works for you. But when I try to write the GUI or the top operational level first, I usually get it wrong. Even if I think I understand the problem, I usually don't. By coding the low-level pieces and beating on them until they work, I usually gain an understanding of what matters and what doesn't and then when I am ready to write the GUI, I know what to do.

QUOTE(bono02 @ Nov 12 2007, 01:26 AM)

Ok, here we also have NI-Elvis. Not me is using it, but my friend. He's teaching undergraduate students. He told me that Elvis is too slow, too many top-level VI which slow the flow of the program. From your experience, what is the maximum level for a sub-VI should be?

I don't know anything about NI-Elvis. If their code is too slow, then it is a design issue, not a problem with excessive VI calls. It is what they are doing in those VIs which must be the problem.

I'm not sure what you mean about maximum level. If it is nesting then there is no max.

QUOTE(bono02 @ Nov 12 2007, 01:26 AM)

I have tried the

LV

FSM toolkit, but for me I don't like it, I can not read the program clearly (maybe because it is using stacked sequence).I am afraid that once I code, a single small changes will ruin everything.

My sentiments exactly.

In C it was easy, you can insert any code in any line you want, but in LabView I feel it is a little bit difficult. Thank you for your suggestion, I will try to use the producer/consumer coding technique smile.gif 3) Thank, I am using two monitors now thumbup1.gif , though I connect to the PXI controller using remote desktop! But still zoom in/out function I think is more comfortable, hehe.. 4) Ok. Thx.Note:Why my reply always ending up and merge with my reply to Jason?

That's on purpose, but it also removed your text formatting, which is a bug. Read more about both here.

[Ton Plomp]

QUOTE(bono02 @ Nov 12 2007, 10:26 AM)

4) Ok. Thx.Note:Why my reply always ending up and merge with my reply to Jason?

It's a bug, but half designed half bug. The part that the two posts merge is intended, the formatting issue not.

To reply to two posts in once use the "+quote" button under every post you want to quote, than hit the "add reply" button on the bottom part, now you'll get a post quoting multiple posts in the right order, and you can remove anything you dislike.

See here

On topic, attending (or buying) the LabVIEW Intermediate I course will be good for you, it focusses on the "Event driven producer consumer" machine. Intermediate II focusses on .net interaction and dll interaction

You can see some design schemes in the Code Repository, the XControl Inheritance Editor uses the "event driven producer consumer" and the Code Capture Tool uses a "Single Event Driven queued State machine"

Ton

[LAVA 1.0 Content]

QUOTE(bono02 @ Nov 12 2007, 03:57 AM)

4. Any body here is using PXI 735x? I searched in this forum, I found only several topics regarding this. I hope we could share knowledge and idea about the motion controller.

Your response is really appreciated.

Bondhan

~Another C programmer who move to LabVIEW

http://bono02.wordpress.com/

Hello

I'm using the PXI 7358- 8 Axis Motion Controller for Servo Motors, and Hydralic Cylinders...

What do you like to hear about the Motion Controllers?

Martin

[bono02]

QUOTE(Norm Kirchner @ Nov 13 2007, 12:38 AM)

bono, depending on what your cost constraints are, and since time is short, and since you're new to LV, and since you're going to be getting into Real-Time hardware. I would strongly recommend finding an alliance partner in your area to help you get started on this. To give you a framework, a background and some idea how to properly code this up.

RT is not a simple task to program properly, especially with the motion control, and w/ the expectation of accuracy and precision. I don't know how much you figured you could learn and implement in a short time, but it looks like you might be over your head.

Your project seems really interesting and my true intent is to help you succeed, not be mean.

Time to call in the Marines.

Hi Norm,

Thank you for your response, here in my place I think it is difficult to find partner. And also I'm living in small town, the NI office is 4 hours from here , and AFAIK I am single fighter NI user in this Univ. Btw, also there's one problem which is language.

[bono02]

QUOTE(martin@aerodynamics @ Nov 13 2007, 04:07 PM)

Hello

I'm using the PXI 7358- 8 Axis Motion Controller for Servo Motors, and Hydralic Cylinders...

I also use the EPOS Positioning Controller from MAXON Motor...

What do you like to hear about the Motion Controllers?

Martin

Hi Martin,

I noticed there are several replies, I appreciate it to Jason and Mike. I will come back later with bunch of questions.

I am planning of buying a rotary encoder, there are two type incremental and absolute. I have understood the difference between

both, and It seems that incremental is suitable to be used with motion controller.

I am thinking of buying incremental, with 3600 resolution, line driver type. I read that the motion

controller can distinguish a signal with 100ns width. What do you think about it, is it good enough?

Thank you

Bondhan

[LAVA 1.0 Content]

QUOTE(bono02 @ Nov 20 2007, 11:38 AM)

I am thinking of buying incremental, with 3600 resolution, open collector type. I read that the motion

controller can distinguish a signal with 100ns width. What do you think about it, is it good enough?

This depends on your application, I can not say if 3600 are just fine or not...

The motion controller (MC) makes a 4 x of your encoder pulses. (If you have a A and B signal)

That mean if you have 3600 counts per revolution, the MC will use 14'400 steps per revolution...

I use encoders from 500 to 10'000 pulses per revolution...

So you have to calculate the resolution you would like to have and then you can choose the right encoder.

We usually use an absolute and an incremental encoder for all axes, since we then don't have to make reference moves...

[bono02]

QUOTE(martin@aerodynamics @ Nov 20 2007, 08:11 PM)

This depends on your application, I can not say if 3600 are just fine or not...

The motion controller (MC) makes a 4 x of your encoder pulses. (If you have a A and B signal)

That mean if you have 3600 counts per revolution, the MC will use 14'400 steps per revolution...

I use encoders from 500 to 10'000 pulses per revolution...

So you have to calculate the resolution you would like to have and then you can choose the right encoder.

We usually use an absolute and an incremental encoder for all axes, since we then don't have to make reference moves...

Hi,

Can you explain why the MC will multiply with 4? Where can I get this information? in which manual?

Btw, the encoder is going to be used for servo motor. For the stepper I have potentiometer feedback.

Thx

[Norm Kirchner]

QUOTE(bono02 @ Nov 20 2007, 08:38 AM)

Hi,

Can you explain why the MC will multiply with 4? Where can I get this information? in which manual?

Btw, the encoder is going to be used for servo motor. For the stepper I have potentiometer feedback.

Thx

The reason for the 4x of the # of pulses is due the the fact that there are actually 4 digital edges present w/ every 1 full notch.

A-up B-up A-down B-down (forward rotation) and since the encoder decoder is smart enough, It can figure out accuracy x4 of the number of notches in your encoder wheel

[Justin Goeres]

QUOTE(Norm Kirchner @ Nov 20 2007, 10:26 AM)

A-up B-up A-down B-down (forward rotation) and since the encoder decoder is smart enough, It can figure out accuracy x4 of the number of notches in your encoder wheel

Also known as http://en.wikipedia.org/wiki/Quadrature_encoder' target="_blank">Quadrature Encoding.

[bono02]

QUOTE(martin@aerodynamics @ Nov 20 2007, 08:11 PM)

This depends on your application, I can not say if 3600 are just fine or not...

The motion controller (MC) makes a 4 x of your encoder pulses. (If you have a A and B signal)

That mean if you have 3600 counts per revolution, the MC will use 14'400 steps per revolution...

I use encoders from 500 to 10'000 pulses per revolution...

So you have to calculate the resolution you would like to have and then you can choose the right encoder.

We usually use an absolute and an incremental encoder for all axes, since we then don't have to make reference moves...

Hi Martin,

I need another help. I tried to find a contour move with different speed configuration in ni.com, but I could not find any.

Is it possible to have different speed for different position in countour move? Do you have example for this?

Thank you.

Bondhan

[bono02]

QUOTE(martin@aerodynamics @ Nov 20 2007, 08:11 PM)

This depends on your application, I can not say if 3600 are just fine or not...

The motion controller (MC) makes a 4 x of your encoder pulses. (If you have a A and B signal)

That mean if you have 3600 counts per revolution, the MC will use 14'400 steps per revolution...

I use encoders from 500 to 10'000 pulses per revolution...

So you have to calculate the resolution you would like to have and then you can choose the right encoder.

We usually use an absolute and an incremental encoder for all axes, since we then don't have to make reference moves...

Hi Martin,

I need another help. I tried to find a contour move with different speed configuration in ni.com, but I could not find any.

Is it possible to have different speed for different position in countour move? Do you have example for this?

Thank you.

Bondhan

[LAVA 1.0 Content]

QUOTE(bono02 @ Nov 21 2007, 01:40 PM)

Hi Martin,

I need another help. I tried to find a contour move with different speed configuration in ni.com, but I could not find any.

Is it possible to have different speed for different position in countour move? Do you have example for this?

Thank you.

Bondhan

There are two contouring modes: Absolute contouring and relative contouring....

http://digital.ni.com/public.nsf/allkb/062...6256C8C00771B57

Just try on NI.com search for contouring

In the contouring modes you write the desired positions into a buffer on the motion controller. Typically you give the motion controller every 10ms a new position.

In the absolute contouring mode you write absolute positions:

If you write 100, the motor will turn to 100 Inc, if you write 200 the motor will turn to 200 Inc....

When you start a new absolute contouring move, the counter will always start at 0! (Not the same as the Absolute Inc. position...)

In the relative countouring mode, you write relative positions to the motion controller.

If you write 100, the Motor will turn 100 Inc starting from the actual position. if you write 200, the motor will turn another 200 Inc starting friom the actal position...

So if you will move from 0 to 100Inc. at different speeds:

Absolute contouring:

Write 0, 1, 2, 3, ...... 99, 100,...100

Write 0, 2, 4, 6, .......98, 100,...100 (double speed)

Write 0, 0, 1, 1, 2, 2,.... 99, 99, 100,...100 (halve speed and so on)

Relative contouring:

Write 100 Times a 1, (followed by zeros)

Write 50 Times a 2 (double speed) (followed by zeros)

Write 100 Times a 0 and 1 (halve speed) (followed by zeros)

So with the update rate and the values you write to the buffer you will give the motion controller the desired speed.

[bono02]

Hi martin,

Thank you for your answer. I tried several times, but the motor only moved a bit.

I tried these steps (stepper motor) with absolute contouring: 1000 2000 3000 4000 5000

with velocity 137795 steps/rev equal to 13 RPS

I don't know why. I think this is the fastest speed of the motor, because if you increase

the speed the motor will not move anymore.

I read in the manual that "no consecutive points can differ by more than 2^15-1", and my steps

are just fine, and also it said that the data in-between two points will be spline-interpolated.

Is it possible to have a position (a b c d e..n) and then just by giving the time from a to n (with the velocity is derived automatically)?

Btw, about the maxon motor, are you using the API provided or you directly drive it using motion controller?

Here with me I have EPOS 70/10 and Maxon motor EC 45.

Thank you.

Bondhan

QUOTE(martin@aerodynamics @ Nov 28 2007, 12:26 AM)

There are two contouring modes: Absolute contouring and relative contouring....

http://digital.ni.com/public.nsf/allkb/062...6256C8C00771B57

Just try on NI.com search for contouring

In the contouring modes you write the desired positions into a buffer on the motion controller. Typically you give the motion controller every 10ms a new position.

In the absolute contouring mode you write absolute positions:

If you write 100, the motor will turn to 100 Inc, if you write 200 the motor will turn to 200 Inc....

When you start a new absolute contouring move, the counter will always start at 0! (Not the same as the Absolute Inc. position...)

In the relative countouring mode, you write relative positions to the motion controller.

If you write 100, the Motor will turn 100 Inc starting from the actual position. if you write 200, the motor will turn another 200 Inc starting friom the actal position...

So if you will move from 0 to 100Inc. at different speeds:

Absolute contouring:

Write 0, 1, 2, 3, ...... 99, 100,...100

Write 0, 2, 4, 6, .......98, 100,...100 (double speed)

Write 0, 0, 1, 1, 2, 2,.... 99, 99, 100,...100 (halve speed and so on)

Relative contouring:

Write 100 Times a 1, (followed by zeros)

Write 50 Times a 2 (double speed) (followed by zeros)

Write 100 Times a 0 and 1 (halve speed) (followed by zeros)

So with the update rate and the values you write to the buffer you will give the motion controller the desired speed.

[LAVA 1.0 Content]

QUOTE(bono02 @ Dec 4 2007, 02:07 PM)

Thank you for your answer. I tried several times, but the motor only moved a bit.

I tried these steps (stepper motor) with absolute contouring: 1000 2000 3000 4000 5000

with velocity 137795 steps/rev equal to 13 RPS

I don't know why. I think this is the fastest speed of the motor, because if you increase

the speed the motor will not move anymore.

I read in the manual that "no consecutive points can differ by more than 2^15-1", and my steps

are just fine, and also it said that the data in-between two points will be spline-interpolated.

Is it possible to have a position (a b c d e..n) and then just by giving the time from a to n (with the velocity is derived automatically)?

Btw, about the maxon motor, are you using the API provided or you directly drive it using motion controller?

Here with me I have EPOS 70/10 and Maxon motor EC 45.

You have to make an array with points by yourself andyou should not change the updaterate of the contouring points to change the velocity...

The data inbetween two points are spline interpolatet, thats true. But this is not like a S-Curve move! So you will have big accelleration when you start a move with big velocity...

If you just send points 1000 2000 3000 4000 5000, then it tries to move always 1000 steps in the updaterate of the countouring points...

When you don't have a closed loop with your stepper motor, it is possible that you loose points...

In the contouring mode you can not just give a target position and a velocity. If you will do that you have to change to the absolute or relative position mode. Then you can enter the target, a velocity and start the move...and the S-Curve also work in this mode...

QUOTE(bono02 @ Dec 4 2007, 02:07 PM)

Btw, about the maxon motor, are you using the API provided or you directly drive it using motion controller?

Here with me I have EPOS 70/10 and Maxon motor EC 45.

I use the API provided..

[bono02]

Hi all, it's me again, don't get bored . For martin thank you for your reply, I already quite finish the contour movement. I realized that the update rate is the time between two points (Thus we can measure the time for the whole trajectory). For somehow if we set the point too far between two points and the update rate can is beyond the speed, then the motor cannot follow the points given. Now the problem is the speed is too slow (though I am using 10 ms), I am thinking of changing the trajectory.

Anyway, I have several problems:

1. I am trying to use the digital IO of the motion controller of 7358, but then I realized the delay is more that 1 ms (I checked using the oscilloscope), I attached the code (MOMO = Must On Must Off). Is this real, I mean the hardware delay between on-of is as big as this? Anyone knows the solution for this?

2. I am using DAC (I attached the code), I read on the oscilloscope that the signal is not really what I want (I think because of the sampling, I attached the oscilloscope output picture). On the oscilloscope it is read that the amplitude is for 10 V, but in multimeter it is only 2 V (I think because the multimeter measured the RMS value). How to generate a real RMS value using DAC in motion controller?

All of this code is downloaded into the LV-RT 8.5

Thank you

[bono02]

QUOTE(bono02 @ Dec 31 2007, 10:01 PM)

Hi all, it's me again, don't get bored . For martin thank you for your reply, I already quite finish the contour movement. I realized that the update rate is the time between two points (Thus we can measure the time for the whole trajectory). For somehow if we set the point too far between two points and the update rate can is beyond the speed, then the motor cannot follow the points given. Now the problem is the speed is too slow (though I am using 10 ms), I am thinking of changing the trajectory.

Anyway, I have several problems:

1. I am trying to use the digital IO of the motion controller of 7358, but then I realized the delay is more that 2 ms (I checked using the oscilloscope), I attached the code (MOMO = Must On Must Off). Is this real, I mean the hardware delay between on-of is as big as this? Anyone knows the solution for this?

2. I am using DAC (I attached the code), I read on the oscilloscope that the signal is not really what I want (I think because of the sampling, I attached the oscilloscope output picture). On the oscilloscope it is read that the amplitude is for 10 V, but in multimeter it is only 2 V (I think because the multimeter measured the RMS value). How to generate a real RMS value using DAC in motion controller?

All of this code is downloaded into the LV-RT 8.5

Thank you

Hi all, I answered my 2nd questions, It is caused by the glitches (see the picture from my previous post). If we use the DAC vi independent from motion axis, we HAVE to disable that axis so that it won't glitch.

Now about the 1st question, any answer? Thx.

[bono02]

QUOTE(bono02 @ Jan 1 2008, 04:05 PM)

Hi all, I answered my 2nd questions, It is caused by the glitches (see the picture from my previous post). If we use the DAC vi independent from motion axis, we HAVE to disable that axis so that it won't glitch.

Now about the 1st question, any answer? Thx.

The problem is solved. In case anyone has similar question, the answer is in http://forums.ni.com/ni/board/message?board.id=240&message.id=5813#M5813' target="_blank">here.