Jump to content
OMRON Forums

dro

Members
 View Profile  See their activity

  • Posts

    44

  • Joined

  • Last visited

 Content Type 

Posts posted by dro

    Tips for decreasing Power PMAC compile time?

    in Power PMAC

    Posted

    Hi,

    please go to Tools->Options menu in the IDE. In the Options window expand the Projects and Solutions node and select the build and run option. in this option, change the msbuild project build output verbosity and msbuild project build file verbosity settings to normal.

    Do a build only and check the output window for the compiling progression of your c apps and visually you can see which one is taking more time to compile. Are you compiling a Realtime routine?

    Tips for decreasing Power PMAC compile time?

    in Power PMAC

    Posted

    Do you do a build and download or only a build? At the end of a build or a build and download we print in the output window all the messages that are generated by the build and download and also we print the total time for build and also the total time for the download process as well, can you share those numbers. I want to see whether the build is taking the time or the download. For the build process portion of the build and download, we upload the libraries from the Power Pmac one time during your first build or build and download process. After the initial upload, the subsequent builds only check the type of the PMAC you are connected to generate the correct make files for the build, which would not consume any time at all.

    Offline build

    in Power PMAC

    Posted

    Before re installing the IDE, what device did you communicate with? To set the original default Power PMAC libraries for a no device build (Libraries that you get on your very first IDE installation) do the following:

    1. Go to the directory: C:\DeltaTau\Power PMAC IDE\compilers\usr\local

    2. Rename "dtlibs" folder to "dtlibs old"

    3. double click on dtlibs.exe and let it extract in the current folder.

    4. check your IDE again to see if you can do a No Device build.

    usralgo size on 465/460

    in Power PMAC

    Posted

    A large kernel object or having debugging information in it has no affect on the performance of a kernel object. We build our kernel object with optimization and the debug info is probably inserted at some point from the specific Linux kernel source that we are using to compile usralgo.ko. Debug symbols of a compiled code are located in a different section of a code/data structure and they are not loaded at the runtime, so those extra symbols would not penalize the performance. what you see in your objdump shows you the debug symbols in the extra sections. you can easily remove the debug symbols from usralgo.ko with the following command: strip --strip-debug usralgo.ko

    you will notice that the size of usralgo.ko will be much smaller, which will be similar to the size of a usralgo.ko compiled for a Power Pmac 460. I will check to see if our cross compiler would support stripping at the compile time and if it does then I will change the make files in the IDE to do so. Nonetheless it has no affect on performance.

    Add .cpp file to realtime routines

    in Power PMAC

    Posted

    Within the IDE, we only support C code across the board, but you can compile c++ code outside of the IDE for the background C Programs. The user servo algorithms are strictly C, since they are running in kernel space so you can not use c++ for the servo algorithms. we also use Matlab and embedded coder to generate c files for custom servo algorithms. Can you generate c instead of c++?

    Release build fails on Math function

    in Power PMAC

    Posted

    your rint() problem is genuine one. When you compile your code in Release mode, we try to optimize your executable. The compiler replaces your original rint() function to a more optimized lrintf() function, depending on the parameter of the function and it's return type. We have our own math library in the Power PMAC and we are not using the standard math library because it is not as efficient as we want it to be. In our math library we have rint() function defined but we do not have lrintf() and that is why you see the error. We have two ways of solving your problem. One way is to use custom make files in the IDE and lower the optimization to stop the compiler from optimizing rint() function. I will explain you more about this route if you decide to use it. The other solution is to declare the lrintf() function in your capp1.c file as the following.

     

    double lrintf(double x)

    {

    return rint(x);

    }

     

    and change your call to:

     

    a=(int)rint(1.5);

    Error: "cp: target 'Routines' is not a directory"

    in Power PMAC

    Posted

    This problem is not an IDE problem, it is a windows issue. To compile a usralgo, we need to get the short path of a folder. On some machines, if you create a folder in the windows explorer, the windows fails to create a short path for that folder. To check your problem, you can open a command prompt, then CD to the directory that contains your project folder and then issue Dir /X command. It will show you the directories with their short path, I am pretty sure your project folder does not have a short path. To check to see if your D: drive have the short path mode enabled do the following command in a command prompt window:

     

    fsutil 8dot3name query D:

     

    if you get the following response:

     

    The volume state for Disable8dot3 is 0 (8dot3 name creation is enabled).

    The registry state of NtfsDisable8dot3NameCreation is 2, the default (Volume lev

    el setting).

    Based on the above two settings, 8dot3 name creation is enabled on d:

    then your d: drive is enabled for short path naming convention. 8dot3 represents the short path naming convention.

     

    To make your project compile (at lease this works for me), zip your project folder, and then unzip it in the D: drive. For some reason if the directory creation is not done manually then windows generates the short paths. After unzipping do the Dir /X command again and check to see if the short path is created, if it is, then you can go to the IDE and it should compile your Realtime Routines

    usrcode doesn't compile in Release configuration

    in Power PMAC

    Posted

    This issue is fixed in the upcoming release of the IDE and you should be able to compile in Release and Debug modes. Project Also creates separate error and message logs for usralgo.ko and usralgo.so and will process and display them in the output and error windows as well. We are planning to release the IDE today.

     

    If usrcode.c is set to compile in the project it works fine in Debug configuration but not Release. Is there some setting I am missing?

     

    It says:

     

    C:\Users\daves.ABD\AppData\Local\Temp\oambyuii.e1j\Temp\PowerPmac6.ppproj(0,0): Error : The compiler was not able to generate an executable file.

     

    This is the symptom of this bug: http://forums.deltatau.com/bugzilla/show_bug.cgi?id=698

     

    Note that there is a crude work-around: build once, let it fail, manually copy bin\Debug\usralgo.ko to bin\Release, then build a second time (should succeed).

     

     

    Please open the following error log file for more information

    C:\Users\daves.ABD\Documents\PowerPmacSuite\PowerPmac6\PowerPmac6\C Language\Realtime Routines\\err.log

    C:\Users\daves.ABD\Documents\PowerPmacSuite\PowerPmac6\PowerPmac6\C Language\Realtime Routines\\msg.log

     

    err.log is empty. msg.log contains: ...

     

    ... and this is the symptom of a different bug (which I'm sure I reported but I can't find just now): compiling C Language usrcode creates two outputs: usralgo.ko and usralgo.so. Unfortunately, both build processes use the same msg.log and err.log files so diagnostics in the first build are overwritten during the second build. The second build can sometime succeed while the first failed, so you end up losing information.

     

    My present work-around is to run the makefiles by hand, one-by-one so that I can examine the logs.

    usrcode doesn't compile in Release configuration

    in Power PMAC

    Posted

    This issue is fixed in the upcoming release of the IDE and you should be able to compile in Release and Debug modes. Project Also creates separate error and message logs for usralgo.ko and usralgo.so and will process and display them in the output and error windows as well. We are planning to release the IDE today.

     

    If usrcode.c is set to compile in the project it works fine in Debug configuration but not Release. Is there some setting I am missing?

     

    It says:

     

    C:\Users\daves.ABD\AppData\Local\Temp\oambyuii.e1j\Temp\PowerPmac6.ppproj(0,0): Error : The compiler was not able to generate an executable file.

     

    This is the symptom of this bug: http://forums.deltatau.com/bugzilla/show_bug.cgi?id=698

     

    Note that there is a crude work-around: build once, let it fail, manually copy bin\Debug\usralgo.ko to bin\Release, then build a second time (should succeed).

     

     

    Please open the following error log file for more information

    C:\Users\daves.ABD\Documents\PowerPmacSuite\PowerPmac6\PowerPmac6\C Language\Realtime Routines\\err.log

    C:\Users\daves.ABD\Documents\PowerPmacSuite\PowerPmac6\PowerPmac6\C Language\Realtime Routines\\msg.log

     

    err.log is empty. msg.log contains: ...

     

    ... and this is the symptom of a different bug (which I'm sure I reported but I can't find just now): compiling C Language usrcode creates two outputs: usralgo.ko and usralgo.so. Unfortunately, both build processes use the same msg.log and err.log files so diagnostics in the first build are overwritten during the second build. The second build can sometime succeed while the first failed, so you end up losing information.

     

    My present work-around is to run the makefiles by hand, one-by-one so that I can examine the logs.

    Kinematics in CfromScript - RealTime Routines from network bug?

    in Power PMAC

    Posted

    Hi Gigi,

    Unfortunately the project would not compile if your project is located on a network drive. Copy your project to your local drive and it should work.

     

     

    Hi all

    I am writing the kinematics of an hexapod system.

    Reading through the forum, it seems that it is advisable using the CfromScript functions instead of the builtin kinematics scripts. I feel also more comfortable in writing the algorithm in C, so this is a big deal.

     

    Unfortunately, I got a strange error when I try to compile the RealTime Routines under the IDE:

     

    		Build Process For usralgo.ko has started.
Z:\100_XXX_hexapod\electronics\XXX2\XXX2\XXX2.ppproj(187,5): Error : cp: target `Routines' is not a directory
	Build Process For usralgo.ko has ended.

     

    At first I tought of a white-space character issue in some compilation layer... However, I tryed to copy the full directory folder on my desktop and re-perform the compilation of the project... and it works! I got other kind of compilation errors (i think because I am using the default usralgo.c, without any modification), but at least the result is different.

     

    		Build Process For usralgo.so has started.
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.c(27,0): Warning :  'struct motordata' declared inside parameter list
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.c(27,0): Warning :  its scope is only this definition or declaration, which is probably not what you want
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.c(28,0): Error :  conflicting types for 'user_phase'
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.h(16,0): Error :  previous declaration of 'user_phase' was here
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.c(31,0): Warning :  'struct motordata' declared inside parameter list
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.c(32,0): Error :  conflicting types for 'user_pid_ctrl'
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.h(13,0): Error :  previous declaration of 'user_pid_ctrl' was here

     

    Is that because the project is located on a network disk, linked under Z:/ ? Is there some path to make it work from the network?

     

    thanks

    gigi

    Kinematics in CfromScript - RealTime Routines from network bug?

    in Power PMAC

    Posted

    Hi Gigi,

    Unfortunately the project would not compile if your project is located on a network drive. Copy your project to your local drive and it should work.

     

     

    Hi all

    I am writing the kinematics of an hexapod system.

    Reading through the forum, it seems that it is advisable using the CfromScript functions instead of the builtin kinematics scripts. I feel also more comfortable in writing the algorithm in C, so this is a big deal.

     

    Unfortunately, I got a strange error when I try to compile the RealTime Routines under the IDE:

     

    		Build Process For usralgo.ko has started.
Z:\100_XXX_hexapod\electronics\XXX2\XXX2\XXX2.ppproj(187,5): Error : cp: target `Routines' is not a directory
	Build Process For usralgo.ko has ended.

     

    At first I tought of a white-space character issue in some compilation layer... However, I tryed to copy the full directory folder on my desktop and re-perform the compilation of the project... and it works! I got other kind of compilation errors (i think because I am using the default usralgo.c, without any modification), but at least the result is different.

     

    		Build Process For usralgo.so has started.
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.c(27,0): Warning :  'struct motordata' declared inside parameter list
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.c(27,0): Warning :  its scope is only this definition or declaration, which is probably not what you want
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.c(28,0): Error :  conflicting types for 'user_phase'
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.h(16,0): Error :  previous declaration of 'user_phase' was here
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.c(31,0): Warning :  'struct motordata' declared inside parameter list
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.c(32,0): Error :  conflicting types for 'user_pid_ctrl'
C:\Users\ut\Desktop\XXX2\XXX2\C Language\Realtime Routines\\usrcode.h(13,0): Error :  previous declaration of 'user_pid_ctrl' was here

     

    Is that because the project is located on a network disk, linked under Z:/ ? Is there some path to make it work from the network?

     

    thanks

    gigi

    C++ background apps?

    in Power PMAC

    Posted

    IDE generates two sets of errors. For each language such as C we have a language service that tries to find syntax errors before they are compiled and they are always shown on the Errors List tab. Sometimes this service shows syntax errors which are not really errors, so do not rely on the errors tab for the validity of your code. It is meant to be a helper but has some issues that needs to be fixed. The correct reflection of the validity of your code happens during the compile time and it's results are displayed in the output window.

     

    piefum:

     

    It looks like the errors are purely aesthetic, and have nothing to do with the compilation (e.g. the compile is succeeding). I think this is because the Delta Tau IDE is using a custom C language parser and it isn't great at recognizing and mapping all of the referenced include files.

     

    However, if the application compiles, then that means everything is working properly. Have you tried to download and run the application after compiling?

    C++ background apps?

    in Power PMAC

    Posted

    IDE generates two sets of errors. For each language such as C we have a language service that tries to find syntax errors before they are compiled and they are always shown on the Errors List tab. Sometimes this service shows syntax errors which are not really errors, so do not rely on the errors tab for the validity of your code. It is meant to be a helper but has some issues that needs to be fixed. The correct reflection of the validity of your code happens during the compile time and it's results are displayed in the output window.

     

    piefum:

     

    It looks like the errors are purely aesthetic, and have nothing to do with the compilation (e.g. the compile is succeeding). I think this is because the Delta Tau IDE is using a custom C language parser and it isn't great at recognizing and mapping all of the referenced include files.

     

    However, if the application compiles, then that means everything is working properly. Have you tried to download and run the application after compiling?

×
×
  • Create New...