Jump to content
OMRON Forums

daves

Members
  • Posts

    261
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by daves

  1. Please can you confirm the units of the timeout parameter of ISyncTerminalCommunicationInterface.ExecCommand

     

    The documentation does not make this clear if it is ms, seconds, years. It looks like seconds when I had to put 10 in to allow a 4s operation to complete, but I want to check this was not coincidence.

     

    The doc is also incorrect for the overload list

     

    "ExecCommand(String, Int32)

    Receive the Operating System(OS) string command or PowerPMAC command and 'out' the OS string response."

  2. Does anyone know how the Capp->Properties->Native Compile Options->Linker Options actually works?

     

    I understand the theory and I can use it successfully in a simple use case. But I need the following:

     

    $(PMAC_ARCH)/UniKey.32.a

     

    to go to the makefile directly as this:

     

    CUSTOMLDFLAGS = $(PMAC_ARCH)/UniKey.32.a

     

    However it gets parsed or something and ends up as

     

    CUSTOMLDFLAGS = /UniKey.32.a

     

    I have tried all sorts of clever things but it looks like some makefile variable expansion is done.

     

    Basically the actual issue is I need to link a different .a file depending on the target architecture, so if anyone knows a clever way to do this please let me know! (I have also tried custom makefiles but can't figure out how to detect the architecture - it is spliced in the auto generated DT ones but not custom ones).

     

    Cheers

    Dave

    link.png.fa0cbcb4b285311aa158ea03abcd3ac8.png

  3. Hi

     

    I thought I would give the v3 IDE a whirl. Very excited about the new shell.

     

    I was asked to install 465 compiler on trying to build.

     

    But, our project does not build. Neither does a blank project with usrcode active:

     

    IDE3Test.ppproj(89,5): error : Makefile:327: /opt/powerpc-465-rootfs/usr/src/linux-3.2.21-serengeti-smp/scripts/Kbuild.include: No such file or directory

    IDE3Test.ppproj(89,5): error : /bin/sh: /opt/powerpc-465-rootfs/usr/src/linux-3.2.21-serengeti-smp/scripts/gcc-goto.sh: No such file or directory

    IDE3Test.ppproj(89,5): error : make: *** empty variable name. Stop.

     

    Indeed kbuild.include and gcc-goto.sh (in fact the whole scripts folder) are not present. They are present on a v2 install.

     

    What went wrong?

    What should I do?

     

    EDIT: A full reinstall didn't fix. It might help to know 460 and CK3E build without error. A quick run in WinMerge between v2 and v3 compilers clearly shows the missing files for 465.

     

    Cheers

    Dave

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

  5. Hi

     

    I'm still playing with my CK3E. I accidentally left it on overnight (a good test as it turns out).

     

    When I came back in I saw my RTIDrop counter I have coded into my RTICPLC high and increasing. Task Manager shows [bsy/Err] red errors flashing up once a second roughly (see attachment).

     

    What has happened? I noticed the occasional count when running normally but wrote it off as happening on download, now I am more concerned. How to debug?

     

    I will test with a blank or no project loaded tonight.

     

    Cheers

    Dave

    armdrop.thumb.png.0024dc598376e71ba5f08dafc5f1b9d6.png

  6. 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?

  7. 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

  8. 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

  9. Got it!

     

    Some editor had managed to get the UTF-8 BOM at the start of the file. I think it converted some ² in the (I guess 1252) ANSI codepage in a comment to the UTF-8 encoding of a different code point.

     

    I found

     

    // Abort deceleration (8 motor units/msec�)

     

    in the file. SVN reported no differences so very hard to track down. Found the "EF BB BF" in a hex editor.

     

    The VS shell seemed to be very stubborn about saving without the BOM even after the file was cleared of bad characters.

     

    Is it the ppmac parser that is not coping with BOMs?

  10. Anyone have an idea of the meaning of the following? I have not downloaded this branch of code for a while so there have been numerous changes.

     

    "C:\ABD\SPMMPowerPMAC_trunk\Phase2\Phase2\PMAC Script Language\Libraries\setup motors.pmc(1,1) : Error : ( error #20) ILLEGAL CMD : open subprog 100020,9,31"

     

    The actual line is "open subprog SetupMotors(void)"

     

    It is in a library which hasn't changed for ages.

     

    I am guessing the actual error is earlier in the script code.

     

    I will start the rollback of all my changes I suppose...

  11. Hi I have had this custom kernel module approach working at my customer's site well for these past months.

     

    I have two more customers wanting to use this feature so I have some urgent question s regarding distribution of DT libraries.

     

    I am going to end up with three customers with different versions of IDE and Firmware.

     

    The building of my custom module uses DT libraries (like the math functions)

     

    My current solution involves distributing the compilers.tar.gz, CompilerExtractProgress.exe files and extracttool folder from my PC to the customer and getting them to run CompilerExtractProgress.exe (I had the same IDE and firmware as the customer at that time).

     

    1) Is this OK?

     

    2) How do the libraries in that gz relate to the firmware on the card?

     

    3) Are they just the libraries distributed with the IDE and not necessarily right for the customer’s firmware?

     

    4) I know there is(was) a strange step in the IDE when first talking to a 465 where libraries are uploaded, is this an issue?

     

    5) I know some files are uploaded by the IDE on a Build command, does the customer need these files (what are they)?

     

    6) I envisage the customer building these modules on a PC not necessarily connected to the PPMAC card, is this possible?

     

    How to best proceed...

  12. Hi I recreated this and agree it would be nice if it was made to work (or the script flow logic explained a bit more - there are other peculiarities which catch you out when switching between the C development and script, or the parser error message explaining what is wrong and how to fix...).

     

    Anyway, my first thought of a workaround with a global "return jump" seems to work and might be good enough? A little clunky:

     

    open plc 1
    local suc;
    callsub sub.doMath(&suc);
    return;
    
    sub: doMath(&success)
    success = -1 //default is failure
    local math = 0;
    
    if (somethingbad==1) goto 9999
    if (somethingelse == 1) goto 9999;
    
    math = 2+2;
    success = 1; //completed
    return;
    
    N9999:
    return;
    close
    

     

    or you could have a "return label" in each sub if that looks better, or this breaks other local variable scope... I haven't played with it too much.

  13. It's not project specific. Projects work at home, not in the office. A blank new project fails in the office.

     

    I have hunted it a bit for you, here are some clues:

     

    * I'm using a 460 card at home, a 465 at work

    * I haven't connected my work system to a 460 since reinstallation of IDE

    * __wrap_printf appears to be in "C:\DeltaTau\Power PMAC IDE\compilers\opt\powerpc-465-rootfs\usr\local\xenomai-2.6.2.1\lib\libpthread_rt.so.1.0.0" at work

    * __wrap_printf appears to NOT be in "C:\DeltaTau\Power PMAC IDE\compilers\opt\powerpc-405-rootfs\usr\local\xenomai-2.5.6\lib\libpthread_rt.so.1.0.0" at work

    * Offline build puts "PMAC_ARCH=ppc405" in the makefile

     

    I haven't checked the libraries at home but could they be different? Maybe they are meant to be different. I'll try to find a 460 at work and connect...

  14. I will attach dumps of the boot text. The interesting differences are:

     

    * The card I have never seen fail is booting in Fast Boot, the card I have seen fail is running fsck.

     

    * The card I have seen fail is running OpenBSD Secure Shell server, what is that?

     

    * The card I have seen fail only has one ". ok" after "initializing module rtpmaclib", is this OK?

     

    I will also attach dumps of the /opt/ppmac folder, why are they different?

     

    I will also attach dumps of "fsck /opt". There is an error on the card I see go wrong, is this a problem?

     

    I don't have access to the other cards that have gone wrong, and those and this one are currently in a working state (i.e. have not latched in to the corrupted state at the moment).

     

    What would you like me to check next?

     

    Cheers

    Dave

    boot_ok.txt

    boot_bad.txt

    fsck_ok.txt

    fsck_bad.txt

    optppmac_ok.txt

    optppmac_bad.txt

  15. OK thanks for clearing up some of that. So what could be causing a 915B file to have text content after executing the app, but then no content (but still 915B) after cycling the power?

     

    So far a colleague has seen it on a customer machine (we are now supplying PPMAC systems and looking a bit stupid), and I have seen it in the office.

     

    When it gets in this state it is repeatable. After manually executing the "mount" command in a terminal it seems to clear up. We have to be able to do this automatically to spare users from terminals, but this is in danger of making the product unusable.

     

    I have never seen it on my machine but my card seems to have some differences. The /opt/ppmac folder has different contents (I forget the names but the ones that have shown the problem have some .sh files and others). Are there different distributions?

     

    Also the office one that went wrong had "fsck: There are differences between boot sector and its backup" with one difference, mine doesn't. A clue? A problem?

     

    We are very worried about this

  16. I have some background C app code which saves data to a file (it doesn't happen very often):

     

    FILE *f;
    
    // Make rw
    system("mount -o remount,rw /opt");
    
    // Open file for writing
    if ((f = fopen(BuildFile, "wb")) == NULL)
    	return 0;
    
    fprintf(f, "Version = 5\n"); // There are more lines than this...
    fclose(f);
    
    // Make ro
    system("mount -o remount,ro /opt");
    

     

    This generally worked but I am getting reports of the file being corrupt after repowering. I have witnessed the file be reported as present and has a size from the ls command. Editing with pico shows an empty zero line file.

     

    The file is present and has content until the power is cycled.

     

    Doing a manual remount from a terminal seems to clear the error.

     

    1) Can you see a flaw in this approach? It seems to be recommended in other posts

     

    2) Would an fsync() call be a good idea?

     

    3) Is there a difference remounting /opt or / ?

     

    4) Is there a problem with the system command from an app compared to a terminal?

     

    5) Is there an application note detailing the filesystem on your card, and what is synced where, and what persists, and the boot sequence? There are a lot of mounts and I would like a fuller understanding.

     

    Cheers!

  17. I can add some information to this. It is possible it is just the IDE timing out. I have noted the timing and output from the serial port below.

     

    I build and download and save. Then from executing $$$:

     

    There are loads of

     

    Xenomai: Posix: closing semaphore "PPMACUserSem0".
    Xenomai: Posix: closing semaphore "PPMACPLCCSem0".
    Xenomai: Posix: closing semaphore "PPMACUserSem1".
    

     

    and similar statements for 23s

     

    Then

     

    Success: ppconfig

     

    Then loads of

     

                    gpg: CAST5 encrypted data
                                             gpg: encrypted with 1 passphrase
                                                                             gpg: WARNING: message was not integrity protected
                                              gpg: CAST5 encrypted data
                                                                       gpg: encrypted with 1 passphrase
                       gpg: WARNING: message was not integrity protected
                                                                        gpg: CAST5 encrypted data
                 gpg: encrypted with 1 passphrase
                                                 gpg: WARNING: message was not integrity protected
    

     

    for 55s.

     

    However at the 1m mark from executing $$$ the IDE times out. This is 18s before the final

     

    Success: projpp

     

    output.

     

    Is there a registry setting to lengthen this timeout? It is clearly not long enough...

  18. This works, thanks.

     

    I think you must have been aware of this before and someone has tried something in the past. I notice in your usralgo makefile for the 465 sections you have the line

     

    #STRIP=i686-meau-linux-gnu-strip

     

    but nothing is done after this.

     

    Anyway I added the following to my makefile at the end of the all:: section (not very flexible but works for me)

     

    ifeq ($(PMAC_ARCH),ppc465-2)

    powerpc-meau-linux-gnu-strip --strip-debug spmmhils.ko

    endif

     

    Can you confirm I am using the correct strip (it differs from your commented out one...)?

  19. Thanks Dro! Great news! Thanks for looking into this, it is a relief. I suspected everything was OK otherwise the card would choke pretty quickly. I just panic easily.

     

    I think I recall the lsmod lists the modules at a reasonable size but I may be misremembering. I guess that means only the needed data sections are loaded...

     

    I'm working from home tomorrow where I only have a 460 but I'll check the strip out on Monday. Can I do this from your Windows (cygwin) environment? If I want to speed up the FTP I will need this. I can't see it at first look but it is late here

  20. Thanks Steve. It's a relief to know you are on the trail. Maybe it's not executing debug code, but that objdump definitely shows the debug sections have made it into the binary doesn't it? Anyway hope it helps.

     

    The performance seems acceptable at the moment. I had my simple simulation running at 8kHz. We only need 2.2kHz at he moment. But obviously it is the execution time that has to fit in that interval and that goes up with complexity. A more advanced simulation was taking 80us and we will want to do more, so every microsecond counts as they say!!!

     

    We also FTP these files back and forth so smaller=faster!!!

     

    Thanks again

×
×
  • Create New...