Jump to content
OMRON Forums

KEJR

Members
  • Posts

    297
  • Joined

  • Last visited

Posts posted by KEJR

  1. I believe this was asked previously (maybe even by me??). You might do a search first to see whats out there.

     

    I currently use an open a TCP socket server in C on the PPMAC and C#.NET socket client on a windows PC, but it should work on MONO as well (I haven't tested this yet, but if Mono doesn't supports Sockets I'd be very surprised).

     

    Others have suggested using the Send() command from PPMAC and have a listener to retrieve the messages. I believe you would have to open a telnet connection and run the getsends command so that the Send() messages would be put out to stdout and therefore sent as text to the Telnet client connection. In some ways this is easier because the Server implementation is already handled on the PPMAC with the telnet (or ssh if you prefer) daemon. Delta Tau might have this prettied up in their communications software, you might ask about it. I chose to open my own socket because I wanted to leave the Send() command for us to use for our own debugging and such.

     

    KEJR

  2. I'm not an expert at PPMAC motion commands, I usually use basic linear moves and do alot of programming for other things.

     

    Doesn't PPMAC have the equivalent of a pause command for coordinate systems running in a motion prog?

     

    Also, why do you need to stop asynchronously? Is this so a user can pause the motion at an arbitrary point in the path and then resume gracefully?

     

    Davis G. described to me a couple years ago a method with a virtual coordinate system for graceful fault recovery (in this case it was for a safeguard stop and resume). This seems like overkill for what you need to do, but it might be worth asking about if you find no other alternatives.

     

    KEJR

  3. I am pretty sure this is a bug. I have defined a variable as follows:

     

    #define AxesEnabled P249

     

    When I type "AxesEnabled" in the terminal or from "GPASCII -2" from Telnet, I get the proper expected response:

     

     

    Can you auto define the variable using the "global" keyword, or do you need the variable explicitly defined to P249? I've used global extensively with Mono without problems. The fact that it behaves "differently" with the #define is interesting. Maybe some under the hood glue that is not present in the C environment, (which is what you are accessing when you do dllimport in the MONO environment).

     

    KEJR

  4. Hi Guys,

     

    Thank you so much. I was sweating a little last night because I had put 3-5 days into the Non volatile memory module that requires fixed mapping to P variables and I didn't see any example code for this. Now we can access the "non volatile" block of P variables from HMI, Script, and C by symbolic name, which was my original intent.

     

    The thing that was throwing me is that I thought I had to incorporate it into the "global" keyword syntax.

     

    BTW, thanks again for implementing the script mode access for P vars, it is very cool. I have one project converted over already and it cleaned up the C code substantially and helps to eliminate mixing up Ptr vars and global vars.

     

    Thank you,

    KEJR

  5. Hello,

     

    I want to use the pmh file to define globals that can be used in both script and C programs but that need to map to *specific* P variables.

     

    something like:

     

    global P1000 MyVarName;

     

    where in C code it translates to "pshm->P[1000]" (using script mode preprocessor define) and in script code it translates to "P1000".

     

    I know I can do:

     

    #define MyVarName pshm->P[1000]

     

    and this will work for C code, but I believe it will bomb in the script environment.

     

    Normally I don't want to know what P var it maps to, but in this case I have a block of P vars (P1000-P1999) that gets backed up to disk and I'd like to specify certain globals as Non Volatile by hard coding them to a variable in this range.

     

    Thanks,

    KEJR

  6. I think this is very nice. Thanks for the idea. Now I just have to decide when is a good time to go through and delete all the GetGlobalVar/SetGlobalVar calls!

     

    I just converted my code last night after getting the script mode thing working. I have to say my code reads much more nicely than it did.

     

    Now if we had C++ we could get pass by reference .... (hint hint).... :o)

     

    KEJR

     

  7. OK, this was fixed by the uninstall and re-install.

     

    I also noticed that my antivirus popped up a message that it blocked projppssfx.exe or something like that during install. I then disabled antivirus and re-ran install with the repair option. Upon rebooting all was well. This may have been the root cause.

     

    Thanks,

    KEJR

  8. I think I found the problem. gplib.h just needs to have the following added to it:

     

    extern int MacroPortOpen( char Mode, unsigned MaxTimeout);

     

    I found reference to this in rtpmacapi.h and it just wasn't listed in gplib.h. I'm not sure why I didn't see this before, but after the fact it was obvious.

     

    I changed the name where it was used in my code, of course.

     

    I don't have access to the machine at the moment so I can't test it, but I'm sure this was the issue.

     

    Should I file a bug with bugzilla, or will this be passed on?

     

    Thanks,

    KEJR

  9. Since you are using a structure, why not just use pointers?

     

    struct AxisObject

    {

    double * Param1; // A parameter each of my axes has

    };

     

    void InitAxes() // Set up the references

    {

    A1.Param1 = &axis1Param1G; // Reference to 'global axis1Param1G'

    A2.Param1 = &axis2Param1G; // Reference to 'global axis2Param1G'

    }

     

    Then instead of using SetGlobalVar(unsigned, double) you just do your pointer stuff:

     

    void AxisWork(struct AxisObject A)

    {

    *A.Param1 = 100;

    }

     

    In some ways its not as nice, I agree, but it works. I guess it would depend on how much of this kind of thing you are doing. With the integer index you kind of get a pass-by-reference kind of thing without dealing with pointers, so it is nice in that regard.

     

    BTW, are you using structures of P vars in C to make things convenient on the C side of the fence? I've not used structures with P vars because on the motion programs it is not structured anyway and you have to resort to naming conventions.

     

    I do like your idea of having both options available. It provides that flexibility seemingly without a problem.

     

    KEJR

  10. Does your pp_proj.h file only have entries for foo and bar in the 'bottom section'? Mine contains the following (edited):

     

    My file *just* has the #define 's and nothing else. I think I'll try uninstall - re-install and hope that I don't have the problems you did. I'll check your other posts, I recall seeing something like that in the last few weeks which lead me to do the repair instead of uninstall/reinstall.

     

    I really like the fact that the script mode has far more readable lines of code and uses the fastest P[] access method.

     

    I was doing alot of application coding in C with lots of Ptr vars and global vars and I found myself passing a global var index to an IO routine more than I care to admit. As you can imagine, this is very dangerous when dealing with real equipment. I had recommended doing something with enums so that the two types could be type checked, but DT came back with the native assign to pshm->P[8192] which is *so* much better IMHO. I had created a macro called "Var()" which did the same thing, but it is so much uglier in the code when you do "if" statements and things like that. I appreciate you not hijacking the thread, but I look forward to hearing your points in the other thread. :)

     

    Thanks Dave,

     

    KEJR

     

  11. I'm currently using the following class as a static C# API for the native PowerPMAC functions (i.e. when running HMI on the PPMAC itself with the video option). [code] class Pmac { public const string DllLocation = "/var/ftp/ppmaclibs/libppmac/libppmac.so"; [DllImport(DllLocation)] internal static extern int InitLibrary(); [DllImport(DllLocation)] internal static extern void CloseLibrary(); [DllImport(DllLocation, EntryPoint = "GetResponse", CharSet = CharSet.Ansi)] private static extern int GetResponse([In, MarshalAs(UnmanagedType.LPStr)] string q, [Out, MarshalAs(UnmanagedType.LPStr)] StringBuilder a, Int32 maxlen, Byte echomode); [DllImport(DllLocation, EntryPoint = "GetPmacVar", CharSet = CharSet.Ansi)] private static extern int GetPmacVar([In, MarshalAs(UnmanagedType.LPStr)] string VarName, ref double VarRetValue); [DllImport(DllLocation, EntryPoint = "SetPmacVar", CharSet = CharSet.Ansi)] private static extern int SetPmacVar([In, MarshalAs(UnmanagedType.LPStr)] string VarName, double VarValue); internal static double GetVar(string VarName) { Double val = 0; if (GetPmacVar(VarName, ref val) != 0) MessageBox.Show("The Following Variable Could not be retreived from the PMAC: " + VarName); return val; } internal static void SetVar(string VarName, double VarValue) { if (SetPmacVar(VarName, VarValue) != 0) MessageBox.Show("The Following Variable Could not be set in the PMAC: " + VarName); } } [/code] I don't know if these are 100% correct but I use all these calls daily on a machine that is running. BTW, I wrapped the SetPmacVar and GetPmacVar() functions so I can do: Pmac.SetVar() and Pmac.GetVar() which I find cleaner. but its a preference thing. KEJR
  12. I also enabled just the enum mode and I am not getting the enumerations, just the old style defines:

     

    //***********************************************
    // "pp_proj.ini" generated C header file
    // For accessing PMAC Global, CSGlobal, Ptr vars
    //***********************************************
    #ifndef _PP_PROJ_H_
    #define _PP_PROJ_H_
    #define foo 8192
    #define bar 8193
    #endif //_PP_PROJ_H_
    

     

    So it would appear that something is missing, right?

     

    Thanks,

    KEJR

  13. Thanks for the prompt replies.

     

    It seems that neither my old project or a newly created on is performing the proper define statements in pp_proj.h even after defining _PPScriptMode_

     

    I did the same thing as Sina with a new project and it doesn't work. See the code:

     

    
    #include    // Global Gp Shared memory pointer
    //----------------------------------------------------------------------------------
    // pp_proj.h is the C header for accessing PMAC Global, CSGlobal, Ptr vars
    // _PPScriptMode_ for Pmac Script like access global & csglobal
    // global Mypvar - access with "Mypvar"
    // global Myparray(32) - access with "Myparray(i)"
    // csglobal Myqvar - access with "Myqvar(i)" where "i" is Coord #
    // csglobal Myqarray(16) - access with "Myqvar(i,j)" where "j" is index
    // _EnumMode_ for Pmac enum data type checking on Set & Get global functions
    // Example
    // global Mypvar
    // csglobal Myqvar
    // "SetGlobalVar(Myqvar, data)" will give a compile error because its a csglobal var.
    // "SetCSGlobalVar(Mypvar, data)" will give a compile error because its a global var.
    //------------------------------------------------------------------------------------
    #define _PPScriptMode_	// uncomment for Pmac Script type access
    // #define _EnumMode_			// uncomment for Pmac enum data type checking on Set & Get global functions		// uncomment for Pmac Script type access
    
    
    //----------------------------------------------------------------------------------
    // To use the functions defined in the Libraries, create a prototype of the function 
    // in this file or in a header file that is included in this file.
    // For Example:
    // If a Library project has been created with the following function and you intend to use 
    // that function in this C file:
    // int MyFunction(int MyVar)
    // {
    //	return MyVar*10;
    // }
    // Then a prototype of this function must be created in this c file or in a
    // header file that is being included in this file. The prototype is the following:
    // int MyFunction(int);
    //------------------------------------------------------------------------------------
    
    #include "../../Include/pp_proj.h"
    
    int main(void) 
    {
    InitLibrary();
    
    foo++;
    bar--;
    //Put your code here
    CloseLibrary();	
    return 0;
    }
    

     

    Where foo and bar are "global" in global definitions.pmh file. The pp_proj.h file confirms that foo and bar are 8192 and 8193 repectively.

     

    I chose the "repair" option on the installation over the Feb 2011 release. Should I try to completely uninstall and reinstall the software?

     

    Also note that our PCs are logged into domains on the server with "my documents" residing on the network. This does tend to confuse some software. For a while the addins were misbehaving although I didn't have to mess with that in the last go-around so I think that much is fixed. I mention this just on the off chance that it has something to do with this not working.

     

    Thanks,

    KEJR

  14. Can you check the gplib.h and see if there a OpenMacro() API available? These are the only ones I found:

     

    Neither MacroOpen() or OpenMacro() can be found in gplib.h. I think I remember one of the C programmers over there (Ed Lay??) saying that they were going to rename this function in the next release to be consistent with the naming scheme to MacroOpen(). It is not present in this header, however. I do see a OpenMacro() in rtpmacapi.h, but I am getting problems when I include this file in addition to gplib.h, almost as if the two headers are mutually exclusive.

     

    Adding an extern function prototype for either function name simply moves the problem from the compiler to the linker, so the function must not exist in the object file I'm thinking.

     

    It should be noted that I am not doing anything involved with the OpenMacro() as I am just calling these functions later on in the code and OpenMacro() was needed at the time to get this to work:

     

    PmacCmd("MacroSlave0,i1145=0"); //Set Positive limit on axis 1 to no function (disable)
    PmacCmd("MacroSlave1,i1146=0"); //Set Negative limit on axis 2 to no function (disable)
    

     

    If this is no longer needed I'd be more than happy to get rid of it. I don't have access to the machine with the Macro drives on it now or I'd just try it.

     

    Any ideas?

    Thanks,

     

    KEJR

     

  15. I wouldn't mess around with monitor PLCs reporting to the HMI and all that if you are controlling this from a C program. The reason is that the C api, command interpreter, and shared memory is powerful and you can do it all from there.

     

    I wrote a function called PmacCallMotionProgramAndWait() that starts a motion program in a coordinate system, waits for it to be done, and handles faults and restarts. Restarts on my system only occurr after an operator acknowledgment, however. You might also want to write one where the motion is triggered and then you can wait for it to be done sometime later on with another C function call. I'd post the code, but it is particular to our HMI system.

     

    The point is that you can do all of this from C and make it modular, thus potentially eliminating mistakes.

     

    KEJR

  16. Hello,

     

    I have a project that compiles and works in the Feb 2011 IDE/Firmware but after installing the Sept 2011 firmware I get the following:

     

    
    PMAC variables are mapped successfully.
    	Build Process For XYOilerMain.out has started.
    U:\QA Power PMAC Project\XYOilerCode\C Language\Background Programs\XYOilerMain\xyoilermain.c(670,0): Error :  'OpenMacro' was not declared in this scope
    	Build Process For XYOilerMain.out has ended.
    

     

    Any ideas? As you can see in the output the project is a background C app.

     

    KEJR

     

  17. I'm not sure if this is 100% correct or completely comprehensive, but this is what I do:

     

    
    int CheckCSClosedLoopAndNoErrors(unsigned CSNum)
    {
    int ret=0;
    
    if(  pshm->Coord[CSNum].MinusLimit ) ret++;
    if(  pshm->Coord[CSNum].PlusLimit ) ret++;
    if(  pshm->Coord[CSNum].SoftMinusLimit ) ret++;
    if(  pshm->Coord[CSNum].SoftPlusLimit ) ret++;
    if(  pshm->Coord[CSNum].I2tFault ) ret++;
    if(  pshm->Coord[CSNum].SoftLimit ) ret++;
    if(  pshm->Coord[CSNum].EncLoss ) ret++;
    if(  pshm->Coord[CSNum].LimitStop) ret++;
    if(  pshm->Coord[CSNum].FeFatal) ret++;
    if(  pshm->Coord[CSNum].AmpFault) ret++;
    
    if(! pshm->Coord[CSNum].AmpEna) ret++;
    if(! pshm->Coord[CSNum].ClosedLoop) ret++;
    
    return ret;
    }
    
    

     

    Any return of non zero meant something bad happened. Any other suggestions of what to check would be welcome but this seems to work for me in the errors I've seen pop up, including FatalFE.

     

    KEJR

  18. I've not used the modbus option, but I have heard that it has some delays. Typical modbus devices I've used (on other systems) max out at 5ms between polling, but I think this is totally dependent on the master implementation. I suspect the modbus implementation is a non realtime driver (aka standard linux ethernet) because I don't think Delta Tau is using a xenomai ethernet driver as of yet (I could be wrong). If this is correct I wouldn't rely on it for any kind of realtime performance.

     

    EtherCAT on the other hand can be done at the microsecond level. Beckhoff boasts a 30us update cycle, but practically speaking I'd expect somewhere between 125us and 500us based on what I've heard from the guys at Delta Tau. Beckhoff does have EtherCAT IO that will respond this fast too, they sell their inputs with either a 30us or a 3ms filter I believe (check their website). EtherCAT will be deterministic whereas modbus is based on TCP and is not.

     

    Any hard facts about the modbus implementation would be nice to see. :o) I could see it useful for comunicating to VFDs or other things where it is more of a setup change rather than a critical high speed operation. It all depends on what you need, of course.

     

    KEJR

  19. In your background C code you can set priorities to get the speed up. You will not want to set it higher than 49 as this can starve your real time processes.

     

    Hello Davis. Just to clarify, when you say setting to 50 or higher will starve the realtime processes are you saying that the delta tau "system" RTOS threads (RTI, progs, etc) are set at 50 and higher?

     

    Thank you,

    KEJR

     

     

     

  20. Does DT or anyone else have a recommendation for a wireless mouse/keyboard that is compatible with the Power PMAC right off the bat?

     

    I tried using a Logitech set that I had kicking around but I couldn't get it to work, I'm assuming its a driver issue with Debian.

     

    Has anyone had any luck with any specific brands?

     

    Have you tried to see if your device is recognized by the linux kernel? If you run "dmesg" before and after plugging in the device you should see the device messages from the kernel. I've only tried two *wired* devices.... one keyboard worked and one didn't.

     

    KEJR

  21. I've tested gpascii over telnet from a core 2 duo machine running windows and c# for the application and from the aspect of network and PPMAC speed I would think it would be nearly equivalent to what you are doing with Android. I was seeing about 1ms response time reading a single P var without doing anything special with my network setups (just on a switch). I haven't personally tested "strings" in the sense of a symbolic name with gpascii. When I run natively on the PPMAC, however, it is capable of resolving the names in something like 10-30us (going from memory here....), so the overhead *shouldn't* be much as compared to the network turnaround time and gpascii overhead of 1ms per query. I'd query the thing in a loop 1000 or so times and check it with a timer in the Android device.

     

    What device are you using with Android? Are you using the native API for android apps or QT/C++ or something else? Is there a way to compile and test on a windows machine, or do you just have a device handy when doing the development? I've tried our HMI with C# for both winforms and GTK# and the thing I like here is that the HMI has a simulate mode that lets you test your look and feel from a windows machine before downloading to the PPMAC or panel computer. I'd like to know if there is another way, especially if I can get into non managed code like C++. We are a small company so our engineers must handle HMI, sequence code, motion control, schematics, etc. It makes it tough to be a specialist on any one area. :o)

     

    Also, if I may ask, how are you dealing with the short life cycles of the Android devices in terms of long term support? This was one thing I was leery of, but I'd like to know if there is a simple solution.

     

    Thanks,

    KEJR

     

     

     

  22. Well, I would need 16 of these, so space and cost wise the axis cards are far more efficient. Also I have to use an external amplifier as the motors I'm using cannot be driven directly by DeltaTau, so the amplifier capacity of the MACRO drive would be wasted.

     

    Regardless, that doesn't get me to the new DSPGATE3 ASIC which is where I want to go.

     

    Have you looked at the Copley Macro amplifiers? I'm using them now and they seem to work very well and interface to a broad variety of motors (we are using Sanyo Denki's with 17 bit encoders). We aren't using any hardware triggering or anything like that to warrant the ASIC chips but I thought some of that could be done over macro too? We are going the other way and trying to get into Macro and Ethercat and eliminate the axis cards completely. Anyhow, good luck with your application.

     

    KEJR

     

     

     

     

  23. Hello,

     

    I'd like to have my system library code define globals like you can do in the *.pmh files, but from C code.

     

    The reason is that I have several system variables I want mapped to fixed P vars, but still use the symbolic string based reads through gpascii from my HMI program. Otherwise I have to have my HMI programs cross reference the P vars with duplicated definitions across different project environments (which is what I do now, but gets into version nightmares if I remap the system vars).

     

    The reason I can't do it in the project *.pmh files is that this is my system library that gets included across multiple projects.

     

    Is this possible/practical to do?

     

    Thanks,

    KEJR

×
×
  • Create New...