Jump to content
OMRON Forums

CK3E Questions


daves

Recommended Posts

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

Link to comment
Share on other sites

  • Replies 5
  • Created
  • Last Reply

Top Posters In This Topic

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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"?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...