Jump to content
OMRON Forums

andyf

Members
  • Posts

    141
  • Joined

  • Last visited

Posts posted by andyf

  1. Thanks Curt. I've been using the motion program below to test accuracy. It generates a output pulse from the Delta Tau every second, which I then timestamp using the timing board hardware. If I run this WITHOUT using external time base I see about 1ms drift every 4 minutes. However, if I run it WITH external time base I see about 12ms drift EVERY SECOND!

     

    So, I've done everything according to our discussion. I am going to take a look at the timing board hardware and see if something is off. Let me know if you think of anything else it might be on the Delta Tau side...

     

    open prog 30

    abs

    linear

    q0=0

     

    while( q0==0 ) {dwell0}

     

    while( q0==1 ) {

    m2023 == 0

    delay 1000

    m2023 == 1

    }

     

    close

     

     

  2. OK, I see where that formula is in the docs now. So, this is just a starting point though right? If I use this formula...

     

    RTIF = 32 cnts/msec (I corrected this from previous reply)

    Type 3 ASIC, thus 8 bits fractional count estimation (per ACC24E3 hw manual pg 23)

     

    ScaleFactor = 1/(2^8 * 32) = 0.0001220703125

     

    Using this value directly, my tests are about +36ms. So if I understand you correctly, from this point on, I have to run tests and tweak this ScaleFactor until I get the accuracy I need. Correct?

     

    BTW, pg4 of the Sync PPMAC to External Events document states that 10 bits of fractional count are used in PMAC3-Style IC. I believe this is wrong, because using this gave me a DeltaPos that was off by a factor of 4. The ACC24E3 Hardware manual says 8-bits, which seems to work.

     

     

     

  3. OK, I see what you mean about using "==" versus "=". It turns out this was not the root of my problem though...

     

    I also realized that the more dead on my EncTable[n].DeltaPos is to the Sys.ServoPeriod, the less drift I see. In fact, I was able to reduce it to a millisecond every 12 moves. Is there a formula to use for setting the ECT scale factor to achieve this? I did it through trial and error until I was as close as possible, and out of scale factor precision.

     

    What is the next step to reduce this drift?

     

    Input signal period 32 microseconds, 50% duty cycle

    Sys.ServoPeriod = 0.44274210000000022

    EncTable.ScaleFactor = 0.000123532954799107

    EncTable.DeltaPos = 0.442742109999999522

     

     

  4. Thanks for the instructions Curt. I was able to get this working on our system. However, I am not seeing the accuracy I had hoped for. For example, my test motion program looks like this:

     

    m2023 = 0

    X1000 tm1000

    m2023 = 1

    delay 4000

    m2023 = 0

    X3000 tm1000

    m2023 = 1

    delay 4000

     

    The writes to m2023 toggle an digital output pin, which I am capturing timestamps on using another piece of hardware. I would expect the move times to be 1000ms...but instead I am measuring +/-20ms of that.

     

    Are there additional adjustments that can be configured or made to improve this?

  5. Thanks Curt. This post is related to my other post on clock accuracy. We have other systems in the observatory (i.e. cameras) that are synced to the same time reference system. I am looking at two options:

     

    1) Have the time system hardware generate a single pulse at the precise start of an observation, and let the delta tau sequence moves relative to that start. The problem here is that if the observation runs for a long time (i.e. 8hours), I am concerned the clock accuracy at 50ppm (either CPU or axis) will drift and things will get out of sync. We can only tolerate a few ms of drift over 8 hours.

     

    2) Have the time system hardware generate a pulse every millisecond from the start of an observation. The delta tau would count these pulses and execute moves at the appropriate times relative to the start. I've written a RTI PLC that accurately counts the pulses (tested for 16 hours straight), but I'm not sure if there is a more slick way to do this.

  6. I have a timing card that generates a pulse every millisecond. I need to trigger a motor to move every n milliseconds. I was planning to purchase a timer/counter card to count the pulses and then generate a trigger pulse to the Delta Tau digital i/o card. However, I am curious if the PPMAC can do the counting accurately...perhaps in a PLC....or if there is another feature of the PPMAC that might help in this scenario.
  7. What is the procedure for changing the root password? Are there any special steps on Linux I need to take besides using "passwd"? Also, how do I configure the IDE to use the new password? It seems to be greyed out on all screens.
  8. I am having the same issue with installation on a new Windows 7 64-bit machine. I also noticed that .NET 4 framework is already installed.

     

    During the IDE install, I get a pop up window with title "MS Visual Studio Shell Isolated" and the message "Cannot find one or more components. Please re-install the application".

     

    If I proceed with the IDE install, it finishes but when I launch it none of the add-ins will load. Each add-in gives an error, for example: "The Add-in 'Tune Control' failed to load or caused exception. Error msg: None Error#: 8013150a

     

    Please advise.

  9. [quote='bradp' pid='688' dateline='1284046430'] [quote='dzrong' pid='687' dateline='1284020740'] Hello, Is there a document or example about how to use ACC-84E about protocol of BISS C and EnDat2.2 with PPmac? Thanks, [/quote] The standard manual is found at this link. It only describes Turbo PMAC http://www.deltatau.com/manuals/pdfs/ACC-84E.pdf?id=634158233091868750 Here is an example on how to use it with Power PMAC: [code] //-------------------------------------------------------------------------------- // Motor Setup Example for Power PMAC // Parts: // Power PMAC 460 CPU // ACC-24E2 for Direct PWM control of a brushless motor // ACC-84E for reading the Biss-C enoder // Brushless motor: MCG IB23820 // Encoder: Renishaw RESOLUTE encoder (Biss-C Unidirectional) //-------------------------------------------------------------------------------- #define NumberOfPolePairs 2 #define SingleTurnRes 26 ptr GlobalRegister->u.io:$A0007C.8.24; GlobalRegister=$18000B // Global Control register, 2 MHz Clock setting ptr Chan1Reg->u.io:$A00020.8.24; Chan1Reg = $211480 + SingleTurnRes // Ch1 Control register, 26-Bit EnDat Encoder ptr PosReg1->u.io:$A00000.8.24; ptr PosReg2->u.io:$A00004.8.24; EncTable[1].type=2; // 24+8 bit read entry EncTable[1].pEnc = Sys.piom + $A00000; // address of lower 24 bit EncTable[1].pEnc1 = Sys.piom + $A00004; // address of upper 8 bits EncTable[1].index1 = 32-SingleTurnRes; // left shift for sign adjustment 32-26=6 EncTable[1].index2 = 0; EncTable[1].index3 = 0; EncTable[1].index4 = 0; EncTable[1].ScaleFactor = 1/exp2(32-SingleTurnRes); // scale back to offset the left adjustment done by index2 EncTable[1].MaxDelta = 50000 * 256; Motor[1].ServoCtrl=1 Motor[1].pLimits=0 // Disable the over-travel limits Motor[1].PhaseCtrl=4 // Commutation Enabled, ADC data is read from two separate registers Motor[1].pEnc = EncTable[1].a; Motor[1].pEnc2 = EncTable[1].a; Motor[1].pDac = Acc24E2[4].Chan[0].Pwm[0].a; Motor[1].pAdc = Acc24E2[4].Chan[0].Adc[0].a; Motor[1].pAmpEnable = Acc24E2[4].Chan[0].Ctrl.a; Motor[1].AmpEnableBit = 22; Motor[1].pAmpFault = Acc24E2[4].Chan[0].Status.a; Motor[1].AmpFaultBit = 23; Motor[1].pCaptFlag = Acc24E2[4].Chan[0].Status.a; Motor[1].CaptFlagBit = 19; Motor[1].pEncCtrl = Acc24E2[4].Chan[0].Status.a; Motor[1].pPhaseEnc = EncTable[1].PrevEnc.a; Motor[1].PhasePosSf = 2048 * NumberOfPolePairs / (exp2(SingleTurnRes) * exp2(32-SingleTurnRes)) Motor[1].PwmSf=60/170* Acc24E2[4].PwmPeriod * -1.15; Motor[1].PhaseOffset= -683 Motor[1].IaBias = 91 Motor[1].IbBias = 99 Motor[1].IiGain = 0.2713674247 Motor[1].IpfGain = 0.0000000000 Motor[1].IpbGain = 1.0380999284 //-------------Phasing Search Method---------- Motor[1].PhaseFindingDac=1200; Motor[1].PhaseFindingTime=40; Motor[1].pAbsPhasePos=0; Motor[1].AbsPhasePosFormat=0; Motor[1].AbsPhasePosSF=0; Motor[1].AbsPhasePosOffset = 0; //------------------------------------- //-------------Phasing based upon absolute encoder / calibration required -------- //Motor[1].PhaseFindingDac=0 //Motor[1].PhaseFindingTime=0 //Motor[1].pAbsPhasePos=EncTable[1].PrevEnc.a; //Motor[1].AbsPhasePosFormat=$0 + SingleTurnRes * $100 + (32-SingleTurnRes) //$00001A06; // 00: Binary 00:TBD 1A:26bits 06:LSB location //Motor[1].AbsPhasePosSF=2048/exp2(SingleTurnRes) //Motor[1].AbsPhasePosOffset = 1634; //------------------------------------- Motor[1].pAbsPos = EncTable[1].PrevEnc.a; Motor[1].AbsPhasePosFormat=$0 + SingleTurnRes * $100 + (32-SingleTurnRes) //$00001A06; // 00: Binary 00:TBD 1A:26bits 06:LSB location Motor[1].AbsPosSF = 1; [/code] [/quote] Brad, In your example above, you state that a global control register value of $18000B is used for 2MHz BiSS-C clock. The clock formula given in the BiSS-C section of the ACC-84E manual is: clock = 100 MHz / ( (M+1)*(2^N) ). If M=$18=24, and N=$0, that comes out as a clock of 4 MHz. Should we use M=$31, N=$0 for 2 MHz? I just want to make sure I don't misunderstand anything here... Cheers Andy
  10. We are looking to write a Linux driver for Ethernet communications with the Power PMAC. We would like to know if the Power PMAC Ethernet protocol is the same as that published in the Turbo PMAC2 HRM. If not, do you have any documentation covering the Power PMAC Ethernet protocol?
  11. We are evaluating delta tau PPMAC for one of our applications. We have an existing software framework consisting of distributed Java/C++ components running on Linux (CentOS 5.5) platforms. One of the reasons the PPMAC appeals to us is the fact that it runs Linux, and therefore the possibility of having one of our components run in the PPMAC general purpose OS communicating directly with the motion controller. This would be different than the standard approach of having the component running on another machine and communicating with the PPMAC using ASCII commands over Ethernet. This C++ component would be responsible for submitting motion requests and watching for completion/limit/error events. It would then report these events back to other components in the framework running on different machines. Here are some of our concerns: 1) Components running in our framework communicate using ICE middleware. Do you see any issues running ICE on PPMAC Linux general purpose OS? 2) Component running in our framework access persistent store using PostgreSql client. Do you see any issues running this client software on PPMAC general purpose OS? 3) The big question is if we run a C++ component in the PPMAC general purpose OS, will it be able to communicate with the PPMAC motion controller via the C API? 4) Does PPMAC use interrupts when end of motion/limit/errors occur? If so could our component running in the general purpose OS register an interrupt handler for these or are they reserved for the RTOS only? Sorry or all the questions...running our s/w on the controller is a new direction for us and we are unsure of the PPMAC Linux capabilities. Cheers!
×
×
  • Create New...