Jump to content
OMRON Forums

pmh preprocessing


Recommended Posts

I have a number of organised pmh include files. It seems there is possibly some single-pass issue when they are processed relating to conditionals. Here is a condensed example:


If I have "global definitions.pmh"


#ifdef FOO
global Bar;


and "more definitions.pmh"


#define FOO


I get errors referencing Bar in script or C code. If I rename the second file "another.pmh" it is fine.


I am guessing there is an alphabetical order to the files. Can you confirm? Also is it possible to fix the next release so this is not an issue?


Thanks, Dave

Link to comment
Share on other sites

  • Replies 9
  • Created
  • Last Reply

Top Posters In This Topic

With further investigation I find that no #defines make it out of the script area into the C area, making them not 'Global' enough for me.


I have worked around that issue with


#define FOO
global FOO;


in a file named 'aa defs.pmh'. The first line makes #ifdef blocks work in the script code. The second line fools #ifdef blocks in the C code to work (at the expense of a variable).


This will not help when I need




to work at some point. Could you implement, or is there a way to get truly global (hard-coded) parameters/conditions like these in script and C?


Cheers, Dave

Link to comment
Share on other sites



The mechanism we intended for providing common access in C and Script to the same variables is the user shared memory buffer. To ensure that both C and Script access the same register, you specify the register directly, and use pointers in both environments to access that register.


From the Script side, you make definitions like these:


ptr MyDoubleVar->d.user:$100;

ptr MyIntVar->i.user:$108;

ptr MyIntConstant->i.user:$10C = 42; // Value set on download, power-up, reset


From the C side, you declare these variables:


double *MyDoubleVar;

int *MyIntVar, *MyIntConstant;


and set the addresses with statements:


MyDoubleVar = (int *) pushm + 0x100;

MyIntVar = (int *) pushm + 0x108;

MyIntConstant = (int *) pushm + 0x10C;


One of the software guys will explain how you can also provide C access to global (P) variables you define in the Script environment. This is easier, and you can pull the same trick of assigning a value in the declaration to use the variable as a constant:


global MyGlobalVar;

global MyGlobalConst = 42;



Link to comment
Share on other sites

The example program which comes with the IDE shows how to use Global/CSGlobal variable defined in the GLobal includes folder and used directly in the C App. The example program is called as DemoBox_4x. On a default location it available under

C:\Program Files\Delta Tau Data Systems Inc\2.0\Power PMAC Suite\PowerPMACProjectExamples\DemoBox_4X\DemoBox_4X.




Link to comment
Share on other sites

Hi Curt


Thanks for your reply. I understand the mechanism of global and ptr variables from script/C (although the MyIntConstant->i.user:$10C = 42 initialising of the variable was new to me and looks useful).


For the last part of my second post, I was hoping for some true notion of a constant.


Your workaround of using a variable to hold a value and read it from script/C does handle the requirement in a practical way. I guess I was coming more from the direction of a software engineer and didn't like the expense of using a variable (a #define would be substituted straight in the code) and the insecurity that any process can modify this variable (the #define would be unchangeable).


I am happy to use variables to hold constants that must be shared between script and C.


I am still hoping for some insight into the workings of the conditional compilation possibilities...



Link to comment
Share on other sites

Thanks for the reply. I am familiar with the ideas shown in the example program. I notice it does use a #define constant but then only accesses that from script. I have come to the conclusion that at the moment I wall share constants between script and C using variables.


The example does not show any conditional compilation and only uses one pmh file.


I would still be interested to know about the defined order of pmh inclusion, and the likelihood of #defines spanning script/C in the future for example to control which blocks of code are compiled.



Link to comment
Share on other sites



I, like you, did not want to have global variables used as constants. In a previous posting on this list I was told how to accomplish it.


Create a dedicated *.pmh file ... I call mine constants.pmh. *Only* put your #define statements in there and you can use them from the script environment automatically. To get them in your C environment you have to include the file exclusively. Unfortunately the paths are weird and have spaces in them, but it works:


#include "../../../PMAC Script Language/Global Includes/constants.pmh"




Some side effects are that some things you can't declare as constants, such as motion program names. I think the IDE keeps track of the motion program names internally on the script side, so if you try to define them with a #define the IDE gets confused. I resigned myself to just using the string name when I'm dealing with motion programs in the C environment and it works well.




Link to comment
Share on other sites

Yes that is correct(suggested by KEJR) if you want to use constants defined under script language and then use it in the C app then you need to include the directory. In the next IDE release we have another example program "PowerPmacMacroExample" shows this feature. For example you can add .pmh file like

"C:\Program Files\Delta Tau Data Systems Inc\2.0\Power PMAC Suite\PowerPMACProjectExamples\PowerPmacMacroExample\PowerPmacMacroExample\PMAC Script Language\Global Includes\sharedcscript.pmh" and then use the constants from this in the C app by including this file

#include "../../../PMAC Script Language/Global Includes/sharedcscript.pmh"




Link to comment
Share on other sites

Thanks, this works for my needs.


Also I found I started using:


#define SHAREDVALUE 42

#ifndef __GNUC__
global ScriptOnlyVariable;


to allow non-C stuff in there for script use but in the end I reworked things to not need this, but useful to know anyway maybe.

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...