Jump to content
OMRON Forums

dro

Members
  • Posts

    44
  • Joined

  • Last visited

Everything posted by dro

  1. Can you please email me your sample application @ dro.ghazarian@Omron.com and also the firmware.
  2. 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?
  3. 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.
  4. We are not planning to make PDK compatible with .net core.
  5. As you noticed we only have cross compilers for c and c++. Unfortunately we will not make a cross compiler for Fortran, you can compile your code on the Power PMAC once you get the Fortran compiler and libraries installed.
  6. dro

    Offline build

    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.
  7. Anil, Please email me your project, there might be a setting in your project that is causing this. my email is: drog@deltatau.com
  8. 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.
  9. You can Compile your C codes without any Power PMAC, but the real Power PMAC simulation is not available yet. It will be available in one of our future releases this year.
  10. Which windows version do you see this issue?
  11. 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++?
  12. Realtime Routines only works with C because it runs in kernel space. C++ is not going to work.
  13. What version of the IDE are you using?
  14. I am working on fixing this bug so it will display errors that fall in that special category. rint was a special case, but I have not seen any errors in using the sin() function. how are you using it?
  15. 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);
  16. start the command prompt in the administrator mode and use the following command to set the 8dot3 naming convention globally fsutil behavior set disable8dot3 0 restart the windows and check to see if it is enabled. the following is a link to an article that explains the use of fsutil in more detail http://www.terabyteunlimited.com/kb/article.php?id=245
  17. 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
  18. dro

    Bugzilla

    they are correct, we are trying to assign correct status to the bugs to be able to fix and track them.
  19. dro

    Bugzilla

    they are correct, we are trying to assign correct status to the bugs to be able to fix and track them.
  20. 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. 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). ... 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.
  21. 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. 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). ... 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...