daves Posted January 23, 2017 Posted January 23, 2017 Hi, I very used to using 460/465 cards. I am in the process of trying one of our fairly large projects on the ARM CK3E board (the project works fine on 460/465). It builds and downloads but some part of the system dies. I have managed to telnet in after a failure and the key line from dmesg seems to be: Xenomai: Posix: closing semaphore "PPMACBKGStart". Xenomai: Posix: unmapping shared memory 0x65abd000. Xenomai: watchdog triggered -- signaling runaway thread 'rtpmac' Xenomai: Posix: closing shared memory descriptor 3. Xenomai: Posix: unmapping shared memory 0x65916000. Xenomai: Posix: closing semaphore "PPMACUserSem0". I am in the process of the classic binary-search investigation method of commenting out half the code and seeing if it dies to track down the cause. I have got as far as somewhere near our UserAlgo.RtiCplc=1 call in a startup PLC called from pp_startup... Questions: 1) Any clue what might be different and cause this? Or where to look? 2) I really liked the RS232 debug option on 460/465. I have found various CK3E manuals but no details of an RS232 connector. Is it on the small header I can see? Cheers Dave
KEJR Posted January 23, 2017 Posted January 23, 2017 Hi Dave, I am very excited to see how the ARM system runs and your experience is the first I've heard of from another user. I take it this is the u-etherlite board that is in production now? I've only seen picture with a brief writeup of the USB A style connector on the front panel. The writeup I've seen says that the LED will turn green if you plug it into a PC (RS-232 adapter mode) and if you push the little button witha paper clip next to it that the LED will turn from green to orange (Where orange is mass storage mode and used to backup/restore the PPMAC filesystem, etc. ). This begs alot of questions, such as does this mean that you can only hook it up to use a rs232 TTY if the USB port is only hooked to a host PC? How does this effect you if you want to use USB peripherals (Keyboard, mouse, USB-serial, USB FLASH, etc) with the PPMAC as a USB host? Are there any other USB ports on this system? I've only seen photos of the front/side projection with one USB port, one EtherCAT, and one ethernet port. Presumably there is at least a power plug for 24V somewhere on the top or bottom. I know from Talking with Delta Tau and reading about the CPU architectures that there is an endian issue between the 460/465 and the ARM CPU. I believe the 46x Power CPUs are Big Endian and the ARM's are little endian. Are you doing anything with 8/16/32 bit words, perhaps in the shared memory? If you are converting from 64 or 32bit words down to bytes (or vice versa) you are going to have a problem running your code unaltered. Here is a good article on endian-ness in relation to C code that I found: https://www.ibm.com/developerworks/aix/library/au-endianc/ Its definitely worth considering. KEJR
daves Posted January 24, 2017 Author Posted January 24, 2017 Hi KEJR Thanks for the reply. I'm not up on the u-Etherlite name. We have a http://www.ia.omron.com/products/family/3545/ FYI it has a micro-B connector next to the 24V power connector on 'top' We relied heavily on watching the serial output on boot and occasionally terminaling in through it so I hope it is on the header pins I can see, or can be brought out some other way... The endianness is the only difference I am aware of (nice link btw - even after all these years I think I get endianness for a week and then the next week I am confused by it again!) I have rewritten all my C code defines based on #if defined(__BIG_ENDIAN__) and this all works portably on simple tests projects. And I have made my (Intel) HMI work using our comms library (actually just removing the byte swaps temporarily until I rewrite it nicely). I will continue the hunt until I find out why my RTI has a 'runaway' condition... Dave Hi Dave, I am very excited to see how the ARM system runs and your experience is the first I've heard of from another user. I take it this is the u-etherlite board that is in production now? I've only seen picture with a brief writeup of the USB A style connector on the front panel. The writeup I've seen says that the LED will turn green if you plug it into a PC (RS-232 adapter mode) and if you push the little button witha paper clip next to it that the LED will turn from green to orange (Where orange is mass storage mode and used to backup/restore the PPMAC filesystem, etc. ). This begs alot of questions, such as does this mean that you can only hook it up to use a rs232 TTY if the USB port is only hooked to a host PC? How does this effect you if you want to use USB peripherals (Keyboard, mouse, USB-serial, USB FLASH, etc) with the PPMAC as a USB host? Are there any other USB ports on this system? I've only seen photos of the front/side projection with one USB port, one EtherCAT, and one ethernet port. Presumably there is at least a power plug for 24V somewhere on the top or bottom. I know from Talking with Delta Tau and reading about the CPU architectures that there is an endian issue between the 460/465 and the ARM CPU. I believe the 46x Power CPUs are Big Endian and the ARM's are little endian. Are you doing anything with 8/16/32 bit words, perhaps in the shared memory? If you are converting from 64 or 32bit words down to bytes (or vice versa) you are going to have a problem running your code unaltered. Here is a good article on endian-ness in relation to C code that I found: https://www.ibm.com/developerworks/aix/library/au-endianc/ Its definitely worth considering. KEJR
daves Posted January 24, 2017 Author Posted January 24, 2017 Turns out the system death was caused by our normal 465 code wanting to run at phase/servo rates of 9kHz/2.2kHz and usually clocked by an Acc24. With no GATE the lines Sys.ServoPeriod = 0.44274211; Sys.PhaseOverServoPeriod = 0.25; get interpreted as setting 9kHz/9kHz. And a 9kHz servo/RTI rate is too much for us! It's a shame it didn't generate a normal watchdog, instead it seemed to unload the rtpmac system without message. I understand if CPUTimerIntr=1 phase and servo are the same rate (although it would be nice to not require this), but I was mightily confused by ServoPeriod remaining at 0.44 yet running at 9kHz. Could this be updated? We actually read this value to calculate some filter coefficients but it could be lying. I think things were also not helped by the etherCAT requirement of 62.5us multiples which I was breaking! I think I can move on now. I also noticed sys.PhaseCount is not incrementing is this to be expected?
curtwilson Posted January 30, 2017 Posted January 30, 2017 A few details: When there is no "Gate" to produce a servo clock input to the processor and Sys.CpuTimerIntr=1 (which is the default for no Gates), Sys.ServoPeriod actually determines the servo update period, rather than just telling the interpolation algorithms the period established by the source ASIC. In any Power PMAC, the phase period is the same as the servo period when Sys.CpuTimerIntr = 1. In the uPowerPMAC (CK3E), the phase routine is a simple shell to pass through to the servo routines -- no "real" code executes in it, not even to increment Sys.PhaseCount. In any Power PMAC, the only function of Sys.PhaseOverServoPeriod is for motors whose servo loop is closed in the phase interrupt, to tell the "sub-interpolation" algorithm in the phase routine what fraction of the servo period to use in the sub-interpolation of a single phase cycle. It does not have any effect on the physical time for either the phase or servo period in any Power PMAC In the uPowerPMAC, it cannot have any use. In your uPowerPMAC (CK3E), if the value of Sys.ServoPeriod is 0.442 (at power-on/reset), the servo update period will be 442 usec (2.26kHz frequency), regardless of the setting of Sys.PhaseOverServoPeriod. But remember that the period/frequency used when the CPU is generating its own interrupt is determined only at power-on/reset, so if you change the setting of Sys.ServoPeriod, the new value will only take effect after a save and reset. Internally, we called this product the uEtherlite while it was under development. Marketing decided to sell it under the uPowerPMAC name.
daves Posted February 1, 2017 Author Posted February 1, 2017 Thanks for the informative answer Curt. I will comment below: When there is no "Gate" to produce a servo clock input to the processor and Sys.CpuTimerIntr=1 (which is the default for no Gates), Sys.ServoPeriod actually determines the servo update period, rather than just telling the interpolation algorithms the period established by the source ASIC. Understood. In any Power PMAC, the phase period is the same as the servo period when Sys.CpuTimerIntr = 1. In the uPowerPMAC (CK3E), the phase routine is a simple shell to pass through to the servo routines -- no "real" code executes in it, not even to increment Sys.PhaseCount. Understood. I'm unsure about the consequences of this 'shell' idea but that is another matter! In any Power PMAC, the only function of Sys.PhaseOverServoPeriod is for motors whose servo loop is closed in the phase interrupt, to tell the "sub-interpolation" algorithm in the phase routine what fraction of the servo period to use in the sub-interpolation of a single phase cycle. OK... I thought in our system it was also doing something with encoder/ADC reading, also something to do with the MACRO ring... We also have some UserPhase code which does stuff we need to execute before the Encoder Conversion Table gets processed, will this be affected? It does not have any effect on the physical time for either the phase or servo period in any Power PMAC In the uPowerPMAC, it cannot have any use. In your uPowerPMAC (CK3E), if the value of Sys.ServoPeriod is 0.442 (at power-on/reset), the servo update period will be 442 usec (2.26kHz frequency), regardless of the setting of Sys.PhaseOverServoPeriod. This is where I get confused. It certainly appears to affect 465s and ARM in different ways when I look at task manager. Unless I am misunderstanding. See below... But remember that the period/frequency used when the CPU is generating its own interrupt is determined only at power-on/reset, so if you change the setting of Sys.ServoPeriod, the new value will only take effect after a save and reset. Understood. I have been doing this. Here are my observations of 2 cards: ARM --- $$$*** sys.servoperiod=1 sys.PhaseOverServoPeriod=0.5 save $$$ Values remain Task manager shows Phase Interrupt | 2kHz | 41us (!2) Servo Interrupt | 2kHz (!1) | 0us Real Time Interrupt | 2kHz (!1) | 12us Background Tasks | 1kHz | 8us Yield to OS | 2000kHz | 1900us 465 --- Repeat above actions Values remain Task manager shows Phase Interrupt | 2kHz | 6us Servo Interrupt | 1kHz | 8us Real Time Interrupt | 1kHz | 13us Background Tasks | 1kHz | 11us Yield to OS | 2000kHz | 1980us This begs question 1. Is this right? This is what I was describing where PhaseOverServoPeriod does have an effect, and ServoPeriod is no longer true. A new question 2. Would you expect the phase tasks to be 7x slower on the ARM when doing "nothing"?
Recommended Posts