Jump to content
OMRON Forums

smr99

Members
  • Posts

    39
  • Joined

  • Last visited

Everything posted by smr99

  1. I'm astonished to learn that pushm + 0 is used by the PMAC itself. Is this documented somewhere? I looked at the Software Reference Manual and the description of Sys.Idata indicates i can be "in the range 0 to ...", with no prohibition about using 0.
  2. We are using firmware version 1.5.8. We have a Background C Program that uses a socket to communicate with a remote machine. The generated Makefile for this program includes a bunch of "-Wl,--wrap,xxx" options including wrapping socket, open, recvmsg, etc. My supposition is that we should be using the xenomai versions of these functions (though I'm not really sure why). However, the actual socket code is located in a Library that the program links to. Oddly, the generated library makefile is missing all these --wrap options, so we are presumably not using the xenomai wrapped functions after all. Will this cause us any trouble? The code seems to work, though occasionally it will lock up. Sometimes this hang is followed by a hard watchdog, but sometimes not. Could the missing wrapping have anything to do with this? Another odd thing: select() is wrapped, but not pselect(). We use the latter to wait on the socket as well as two FIFOs sending data from an RTI CPLC. Is this a concern? We actually don't use the signal masking, so we could revert to simple select().
  3. This is a very useful document. Could you comment on the necessity of using SCHED_FIFO and priority=49? I have inherited some code that creates a number of threads in a Background C Program in order to log to the disk and also to communicate over a socket to a remote computer. This code does not call pthread_setschedparam() to change the scheduler or priority. This seems like it should be OK, because these tasks are not time critical. Could this cause us trouble?
  4. I'm confused by that response. I am certainly able to build the entire project on my windows machine. Observing the build process leads me to believe that all the required header files are present on my windows machine, within "C:\Program Files (x86)\Delta Tau Data Systems Inc\2.0\Power PMAC Suite\powerpc-460-linux-gnu". All the .out, .so, and .ko files are generated. I presume correctly. I have since discovered that the build products are not sufficient, however. After placing then in /var/ftp/usrflash, one has to run "projpp". Perhaps that is what you mean. This leads into my next question. Let's assume that I do the proper build & download and have the project running properly. Can I simply copy /var/ftp/usrflash onto a flash disk (under PowerPMAC) and boot up another Delta Tau to load the code (per http://forums.deltatau.com/showthread.php?tid=572 )? -Steve
  5. I would like to create a build on a specific build machine and load it into our systems for testing. We are using firmware 1.5.x, so I understand from that thread that we should create a folder "PowerPMAC/usrflash" that contains the build. The step I am missing is: how do I create the contents of usrflash? I can successfully build the project on my build maching using the IDE with "no device". Then what goes into "usrflash"? In particular, the contents of /opt/ppmac/usrflash contains things that do not appear in my build: directories Database and Temp for one. For another, there is a whole bunch of files in /opt/ppmac/usrflash/Project/Configuration that do not appear on the build machine. And finally, the output files on the build machine all appear in "bin/Debug", but the corresponding directory is empty in /opt/ppmac. Instead, the outputs are scattered into various places under "C Language", namely Libraries, Background Programs, Realtime Routines, CPLCs/user and CPLCs/rti. To be perfectly clear: we have almost no script files, but we do have C-Language servo routines, RTI, and Background Program. Thanks, -Steve
  6. That turns out to be correct, to my surprise. As you note, the sqrt() prototype is for double, so I actually expected a compile error. And I was blaming Delta Tau. But I just tried the same code on a pure linux machine with gcc and discovered that with no optimization, the code does indeed call sqrt() -- presumably after promoting the argument to double -- but with optimization (even just -O1), it changes to call sqrtf(). So this is either a GCC optimization or Standard C. Interesting. Anyway, as you guessed, an explict cast of the argument fixes the problem so I'll do that.
  7. I have a bunch of C-language "Realtime Routines" code. Using the DT IDE to build in Debug configuration, I end up with two files in Bin/Debug: usralgo.so and usralgo.ko. When I build in Release mode, I end up with Bin/Release/usralgo.so, but the ko file is still written to Bin/Debug. I guess this is because the generated Makefile is buggy; it contains: all:: cp -f /opt/eldk-4.2/debian_rootfs/opt/ppmac/usralgo/usralgomain.c $(PWD) $(MAKE) -C $(KSRC) SUBDIRS=$(PWD) modules mv -f usralgo.ko ../../bin/Debug/ So my question is: can I go ahead and use this ko file, or is the build process buggy in additional ways that make this dangerous?
  8. I have a C-language Background Program that uses a C-language Library. There is a library function that contains the following: float Foo(float x) { return sqrt(x); } Using the Delta Tau IDE, this compiles in Debug configuration. In Release configuration, however, while the library itself compiles, the background program fails to link. Oddly, the IDE claims the build succeeded and its build window doesn't show any error. But the background program's ".out" file is not created and its "err.log" file contains undefined reference to `sqrtf' What's going on?
  9. Hi, I've noticed that the Debug configuration compiles C code using "-g3" whereas the Release configuration compiles using "-O2 -Wall". I'd really like to see the warnings from -Wall in Debug configuration. How can I modify the gcc compile flags to add -Wall? Second use case is that a lot of our code breaks "strict aliasing" rules -- too much to fix. So I'd like to add the flag -fno-strict-aliasing to the compile flags. Thanks, -Steve
  10. Thanks, Sina, We don't yet know whether there is enough processing power; I was just exploring options should it turn out not to be. We're thinking of using a PMAC for master/slave control of two manipulator arms and the concern is whether we can run the kinematics, haptic feedback, and collision detection at 1kHz for both arms on one PMAC. As I say, we haven't done the analysis yet.
  11. What options are available if one power PMAC doesn't have sufficient processing resources? Can we put 2 or more Power PMACs in one chassis? Can we plug in a PC 104 or similar board into the system?
  12. smr99

    USB ports

    Hello, The hardware manual (for "Power PMAC UMAC CPU BOARD" -- is that the right one?) lists 2 USB ports on the board. Can these USB ports be used for device control?
  13. Sina, Thanks for the reply. I'd like to clarify a couple of points. I expect you meant to say "Telnet and SSH servers" -- i.e. that I can telnet to the PMAC device from my PC. Is that correct? So it sounds like I can telnet/ssh to the PMAC, log into the linux machine, then run "pgascii" on the machine that provides a command-line interface to the realtime loop. Have I got that right? This will allow me to view and change parameters (e.g. turn on/off a motion scaling mode) of the realtime loop? If the above is true, it sounds like the PMAC has enough horsepower to run my putative lightweight RPC; it shouldn't be any more demanding than the SSH server. My preference is to avoid using gpascii, for a couple of reasons: 1. The PMAC is done by another group and I'd like to define an interface at a high level. I worry that using gpascii means that my PC would need intimate knowledge of the PMAC details, making it hard for them to evolve the PMAC software without affecting me. My hope is to define the interface at a "message" level using an Interface Description Language and leave the PMAC group free to modify things without breaking this interface. 2. I'd prefer to avoid string processing on each end by using a binary packet format. Is this approach feasible? For example, is there a C++-callable API on the linux side that provides a mechanism to view and modify the realtime loop? Is there another way to achieve my goals? Are there examples of systems that do this without using gpascii? Thanks, -Steve
  14. I don't have a Delta Tau system, but we're about to embark on a project that includes one. I'm responsible for an auxiliary workstation that is to do perform set-up and present status of the Delta Tau. The two systems will communicate over ethernet. The workstation will send commands to the Delta Tau (e.g. "give me your status") that will return results. Naively, that seems like a "remote procedure call". Is it reasonable to implement it this way? For example, to run a server on the Linux side of the Delta Tau that accepts commands and returns results over a TCP socket? Would this process be able to access state of the Real Time side (e.g. to return system status)? I'm thinking of using a lightweight RPC library like Apache Thrift [ http://incubator.apache.org/thrift/ ]. I'd appreciate knowing whether someone has tried this or whether this is a bad idea for some reason. Thanks, -Steve
×
×
  • Create New...