Jump to content
OMRON Forums

setting up P-variables


windell747

Recommended Posts

Hi,

 

I'm working on an existing project that using a background program that loads some P-variables with floating point constants that are then accessed by a motion program to make decisions. I'm adding some new P-variables and I'm having a bit of trouble.

 

Can someone outline the process to properly add more P-variables?

 

What I have done is the following:

1) I've added the variables to global_definitions.pmh in the form

 

#define {variable_name} P400

#define {variable_name2} P401

...

 

2) I've added the variables to globalp.h in the following way

#define {variable_name} pshm->P[400]

#define {variable_name2} pshm->P[401]

 

3) The C code uses these macros.

4) The motion program accesses these variables using the same names.

5) globalp.h is included in the C files that access these P-variables.

...

 

Is there anything that I'm missing to do? From my method above it looks like I'm doing things manually, but the PMAC manual seems to imply that these is a way to assign and name the variables via the IDE... How do I do this?

Link to comment
Share on other sites

  • Replies 12
  • Created
  • Last Reply

Top Posters In This Topic

Hi Windell,

 

I highly recommend using the IDE's auto assign feature and accessing C variables with the script mode macro defined in your C program. This allows you to do exactly what you want to in terms of programming by variable name in C and motion progs and adds many other benefits.

 

Let me explain:

 

in your PMH file you use assignments like this:

 

global MyVar01;

global MyVar02;

 

etc.

 

You can also add additional PMH files if you want to, they all get combined in the compile.

 

In your C code you have the following defined and included, in this order:

 

#define _PPScriptMode_
#include "../../Include/pp_proj.h"

void MyFunction()
{
   MyVar01++;
   MyVar02 = MyVar01 + 3.1415;
}

That's it..

 

Now in your code you refer to your variables by name, both in C code *and* in the motion programs! The icing on the cake is that you can type in your variables by name in the terminal and plot/scope tools and it just works.

 

Under the hood the IDE is assigning and defining these for you in both the PMAC script environment and in the C include file "pp_proj.h"

 

It looks like your predecessor was making duplicate defines in separate files (one for script and one for C program). I strongly discourage this because its more work and adds room for error. Maybe this was done in the early days of PPMAC, I don't know. If you can I'd advise to add your couple of variables using my method and see if it works and breaks anything in the compilation. Over time I would encourage you to start moving your #define statements to "global" statements and letting the IDE auto assign. It shouldn't be a lot of work with a text editor with column delete/insert and/or lots of Find/replace.

 

Do you have any other software that accessing these by some hardcoded means? If you do just be careful in converting to all named variables. If your HMI or other software refers to your variables by name then you are likely OK but if they are hardcoded to "P100-P200" or whatever then you might be hosed and have to redefine them in those pieces of software somehow.

 

Let me know how this goes...

 

KEJR

Link to comment
Share on other sites

Thank you KEJR! This really helps me a lot. You know one thing that I haven't found any mention of in the users manual is the line

 

#define _PPScriptMode_

 

I tried compiling without this line, and the variables weren't recognized in the C program. It compiled fine when I put it in though.

 

What does this do? Do you know where I can find mention of this in the manual? I am looking at the System Global Variables section in the manual and I see no mention of it. I just want to make sure that I have all of my bases covered.

 

thanks again!

Link to comment
Share on other sites

Hello,

 

The script mode is in response for a request of mine to have a way of using P variables by name rather than calling a function to get/set the values. I had also expressed concern that ptr vars (M vars in turbo PMAC speak) and global vars (P vars) could be easily interchanged in the user code to potentially bad results. The script mode uses an enumeration for ptr vars and globals are of type double since they are accessed directly in shared memory. So if you try to pass a double type to a function expecting an enumeration you get a compiler error instead of a runtime error, which obviously is much more preferred!

 

So when you do the script mode the IDE generates the pp_proj.h file with some #ifdef statements in it. One of these conditions is the script mode. Open the file and read it, you can tell what is going on. I think the DT guys did this because they wanted to provide this functionality but they didn't want to break existing programs. I can respect that. So I hope this explains why your code only works with script mode defined?

 

I find the manuals confusing. They are very hardware/instruction oriented. Like many things Delta Tau there are a half dozen or more ways of doing the same thing. Many of the manual entries and examples speak of the register and local variable assignment but in the IDE all of this is taken care of for you under the hood. I don't need to know which local variables my named locals are assigned to, I just want it to be taken care of by the compiler in much the same way as a C compiler hides register/stack variables from you. DT has done a decent job at making the motion and PLC programs more "C" like so keep this in mind and ask questions if something looks odd.

Link to comment
Share on other sites

The description of the usage of “_PPScriptMode_” is found in the “PowerPMACProjectExamples” directory of the IDE installation in the example project “Program Development” in the “Documentation” folder. The document titled “Program Development” describes this and many other features. There are two other documents in this folder describing program development features and usage.
Link to comment
Share on other sites

Could you guys post these documents with the other documentation on the website or something like that? It would never had occurred to me to look for the PDFs under an example program directory. Maybe put them in a documentation folder in the install directory and perhaps even a shortcut to the docs during install? These would have helped me a bit when doing my first subprogram.
Link to comment
Share on other sites

I agree it is not an obvious location. I have just seen these and they contain a lot of useful PPMAC information which I remember learning the hard way years ago.

 

I would suggest as a minimum they should be tidied and in the file depot manuals section, and considered for merging in the UG or SRM. They seems to have some overlap with these and each other (even with differing definitions of the same things)

 

My preference would maybe be a new Programmer's Guide with this information and pertinent information from the other manuals collated and organised for programmers (I am obviously biased!).

Link to comment
Share on other sites

Hi Dave,

 

My preference would maybe be a new Programmer's Guide with this information and pertinent information from the other manuals collated and organised for programmers (I am obviously biased!).

 

I tend to agree with the above statement. I think it could help people to see the information from a fresh PowerPMAC point of view and be organized by basic sections and from a beginners perspective. Sections like Data Types, Basic Syntax, and program types. I'd leave out details and advanced features for the most part.

 

the other confusing thing is that the example programs have some not so great things in them. For instance the example listed by Steve in the above post has a static buffer (i.e. known size array) declared using malloc() and it uses #defines in the C code as opposed to the global PMH files and including pp_proj.h, and a while() loop to handle return code on the Send function (this one puzzles me). From my perspective this is very confusing and could lead the new user who may not be an expert C programmer toward using poor programming practices. I can kind of see where they might have been coming from the angle of "look how flexible this is" but I would prefer to see using something like a very clean C program using a "best practices" approach.

 

Please take this as constructive criticism (all DT guys reading this). I would not mind helping with an example C program that I consider to be clean and best practice and post it for review, for example. This is kind of getting off the track of the original post, but if there is any interest for updated manuals or examples maybe we can do a new post? Let me know if anyone is receptive to this.

Link to comment
Share on other sites

The closest thing we have to this is the Power PMAC 5-Day Training slides. You can get them on FileDepot under Power PMAC-->Training Slides-->Class Slides. It's basically just a distilled, yet comprehensive, introduction to the product. It covers motor setup, PLCs, motion programs, and C (it even discusses PPScriptMode!).

 

Please read it as it took a ton of work.

Link to comment
Share on other sites

Gosh, I'd hate to create enemies at DeltaTau, since I'm a huge fan of your controllers! On the flip side, I do think it would be of great help to have a beginning users guide that includes going beyond setting up the motors, coordinate systems, and encoder tables. Of course assuming that the user already knows how to program in K & R C.

 

For me more proven examples from a C-program interfacing with a continually running motion program, blending, timing issues would be wonderful. Maybe a case study approach? I've found that I have to piece information between the SRM and UG to get a full picture sometimes. It makes me wonder sometimes what I'm missing. From the user guide perspective I feel that the C program and motion program part at the end is lacking.

 

For me I learn most effectively by analogy so I tend to like to see the big picture application first and then the implementation. I find that I can come up with a solution way faster than reading cover to cover looking through the UG to piece together the features I would like.

 

I strongly believe that something like this will save a lot of time and money on DT's side by them not needing to answer as many "basic" questions.

 

Again, I hope there are no hard feelings here :) I'm only trying to help.

 

BTW, I'll be attending the DT PMAC class later this month so it will be great to see where the magic happens!

Link to comment
Share on other sites

Thanks Charles! These slides are very helpful and I can see that they took a vast amount of time. I have a copy of them right next to my UG and SRM. I like that it takes the perspective of starting with a new PMAC.

 

The closest thing we have to this is the Power PMAC 5-Day Training slides. You can get them on FileDepot under Power PMAC-->Training Slides-->Class Slides. It's basically just a distilled, yet comprehensive, introduction to the product. It covers motor setup, PLCs, motion programs, and C (it even discusses PPScriptMode!).

 

Please read it as it took a ton of work.

Link to comment
Share on other sites

K & R C. <--Cute reference

 

For me more proven examples from a C-program interfacing with a continually running motion program, blending, timing issues would be wonderful. Maybe a case study approach? I've found that I have to piece information between the SRM and UG to get a full picture sometimes. It makes me wonder sometimes what I'm missing. From the user guide perspective I feel that the C program and motion program part at the end is lacking.

 

I agree that this is a good idea and I will try to write something like this when I get time, maybe next week.

 

Also if you have anything of this nature, KEJR, feel free to post since I value your material too.

 

Bug me about it if I forget! You have my email.

Link to comment
Share on other sites

Thanks very much Charles!

 

I should probably add that my application requires tracking targets that are constantly moving. They aren't moving too fast, but after the steps coming in, new positions are still coming in as the telescope is responding to the step.

 

Right now I'm not in dire need of these examples, just was moreso giving input for my specific application. I'm sure responding to these is like drinking water from a firehose!

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...