Jump to content
OMRON Forums

pennells

Members
  • Posts

    44
  • Joined

  • Last visited

Posts posted by pennells

  1. I see to be missing something. I did all of the above and try to drive the virtual joint in open-loop or closed-loop and it doesn't move (like the brakes are on). The Dac shows it's being driven and, in closed-loop, the following error goes up but the actual position and velocity does not change. I figure it must be some simple setting somewhere that I missed but cannot figure it out.
  2. If your code can work on the data before it goes to our PID or after our PID has worked on it then it is not hard in a normal user servo.

     

    double user_pid_ctrl(MotorData *Mptr)

    {

    // Your custom super duper filter probable more than incrementing a P variable

    pshm->P[100] += 1.0;

    // The default servo algo.

    pshm->ServoCtrl(Mptr);

    }

     

     

    Thanks, that is exactly what I needed. I had problems for a bit because my routine had a return (of zero) which trashed all the motor data but I've resolved that and this solution works just as desired.

  3. Is there any way to find out the address of the boards without taking them out. We have 1 Acc24E3 (reported as ACC24E3[0]) in slots 1 and 2, two Acc24E2As (reported as ACC24E2A[6] and ACC24E2A[7]) in slots 3-6, and the one ACC-36E (reported as ACC36E[1] which I do know is at $B00000) in slot 8. (Assuming the Power PMAC is in slot 0).
  4. So I did as you suggested and got the exact same results. The lower pair values are in the AdcDemux.ResultLow[0] and AdcDemux.ResultLow[4] registers but the high pair values are not in AdcDemux.ResultHigh[0] or AdcDemux.ResultHigh[4], they just read 0. The connections are exactly the same so the values should be within a couple of bits of each other.
  5. No, we were only testing #1, #5, #9, and #13 so we set the second convert code to $400 (for #5 and #13). #5 works correctly but we do not get #9 or #13 on the high element. We already have the base addresses set to $B00000. Even if the second convert code were wrong, the first one should have given us #9. (Forgot to mention, I already set AdcDemux.Address[1] = $B00000 as well.) When I get a chance (tomorrow), I will try setting them all as suggested but I can't see how that would make a difference.
  6. We're having problems accessing data from the upper channels (9-16) of our ACC36E. Our board is at $B00000 so we've set up the following:

     

    AdcDemux.Address[0] = $B00000;

    AdcDemux.ConvertCode[0] = 0;

    AdcDemux.ConvertCode[1] = $400;

    AdcDemux.Enable = 2

    AdcDemux.ResultLow[0] does contain result {Analog In #1}

    AdcDemux.ResultLow[1] does contain result {Analog In #5}

    AdcDemux.ResultHigh[0] should contain result but doesn't {Analog In #9}

    AdcDemux.ResultHigh[1] should contain result but doesn't {Analog In #13}

     

     

    We're reading a unipolar device between pins 1 & 9 using the voltage out between pins 7 & 6. Since all four connectors are the same, we moved the device around to each spot to test the values. The values for 1 and 4 are just as expected but we do not seem to get anything from 9 and 13.

     

    After setting Acc36E[1].ConvertCode=0, I also looked at Acc36E[1].ADCuLow (for #1) when the data showed ready and it was correct but Acc36E[1].ADCuHigh (for #9) again showed nothing.

     

    Did I miss a step or something? What would make the Low registers work and not the High ones?

  7. Yes, you have to use one for each element at this stage. Are you using Real-Time Workshop embedded coder to generate servo code, or a background program?

     

    Hopefully, we are doing both. That is our current goal.

  8. Can you use the PPMAC_INPUT and PPMAC_OUT blocks to access structures in the shared memory or do you have to use one for each element. I suspect the later because the support for passing of structures in SIMULINK seems to only have been implemented after version 7.6 (R2010b). It's just a pain to have to place a symbol for every element in the interface.

     

    Also, I'm not sure if it has been fixed yet but the version of the DELTATAU PPMAC Library which we have has PPAMC_INPUT (instead of PPMAC_INPUT) --obviously not important.

  9. I was wondering if there is any bug-tracking database for the Power PMAC firmware and OS. For the project on which I am working, we have to closely track 3rd party software/firmware for version identification, known issues, and control. For control of the software, the issue is quite easy using the backup utilities for the Power PMAC but, for issue tracking, the solution is not so clear.

     

    I also seem to have a problem when running a full backup of the Power PMAC. It reports "Unable to save version info. This may be a problem when restoring this configuration. Do you still want to backup configuration?" This can be a major problem later on when we want to ensure that all of our systems have the same configuration.

  10. ACC-72E uses different Hilscher modules for different protocols. Here is a list of Hilscher modules which are being used on ACC-72E:

     

    Module       Fieldbus 
    -----------  -----------------
    COM-DPM      Profibus Master
    COM-DPS      Profibus Slave
    COM-CA-DNM   DeviceNet Master
    COM-CA-DNS   DeviceNet Slave
    COM-COM      CanOpen Master
    COM-COS      CanOpen Slave
    COM-CNS      ControlNet Slave
    COM-CN-CCS   CC-Link Slave
    

     

     

     

     

    Can any of the CanOpen versions be used to run raw CanBus communications or does the CanOpen layer have to be included?

     

  11. Pennells,

     

    USB port in Power Pmac is only host port and not a slave port. No Power Pmac IDE or telnet or SSH connection can be made through USB port. However, you can plug a USB to Serial converter to Power PMAC and send your data that way. Would this be an accptable option for you?

     

    No, it's okay. I will just use one of the Ethernet ports. But I guess you are telling me that I can use the RS232 port as an IDE or terminal connection?

     

    Actually, just found out about the ACC-72E. We may be able to do everything using a CanOpen system. The card isn't easy to find from the Delta Tau sight without knowing it exists. I was trying hard to find some sort of communications card and additional communications function to another card.

  12. Is there anyway to utilize one of the USB ports (probably the USB 1 port) to input real-time data for use in the motion control system and therefore minimize the latency down to the 5ms ball park. It would appear that you can tweak the standard Linux RT to do it but I'm not clear on weather you can do it on the Delta Tau version since the documentation implies that only the Power PMAC tasks are "foreground" and that the other tasks are part of the GPOS and therefore lower-priority background tasks. I planned to use the ethernet to output telemetry in real-time and need a serial input portal to read data with less than 10ms latency. Before I go too far down this path, I wanted to confirm that it is even possible.
×
×
  • Create New...