pilotchute

I may have misread the spec. However I did try many encoder clock speeds while trying to debug this. (including the default $63000b, for 1.0MHz) I'll set it to 1MHz for now, and see if that at least improves the behavior.

We are using a Renishaw Resolute BiSS-C 26 bit encoder to determine the absolute rotational angle of a telescope aperture wheel. The following issue has become the last bug in our system. Upon boot or a reset, the encoder may correctly relay the absolute position, or may show the relative position from where it was at the time of the boot or reset. This inconsistent behavior is strange given that it is occurring on a reset, when the starting conditions should be identical. The relevant register values are as follows: For the 25MHz read speed of the encoder Acc84B[0].SerialEncCtrl=$03000B For the format of the 26 Bit BiSS C signal Acc84B[0].Chan[3].SerialEncCmd=$21149A The EncTable values EncTable[4].pEnc=Acc84B[0].Chan[3].SerialEncDataA.a EncTable[4].pEnc1=Acc84B[0].Chan[3].SerialEncDataB.a EncTable[4].type=2 EncTable[4].index=0 The Motor values Motor[4].AbsPosFormat=$1a00 Motor[4].pAbsPos=EncTable[4].PrevEnc.a Motor[4].pAbsPos<2-4>=0 Motor[4].pEnc=EncTable[4].a Motor[4].pPhaseEnc=Acc84B[0].Chan[3].SerialEncDataA.a At this point, I've run out ideas for where to find the cause of this behavior. I'm hoping someone here will be able to help. _ Austin Kootz

Sure. It's in the code block below. It may not cause a runtime error, but the IDE throws a warning, so I switched it out prior to installing it on the PMAC. open plc 1 local pins = 0; local pin = 0; local notpin = 0; local pinnum = 0; local pinactive = 0; local ionum = 0; //This PLC is intended for reading limit switches and setting the appropriate GPIO pin high if the limit switch is active. ionum = 0; pinnum = 0; pins = Gate3[0].gpiooutdata[0]; pin = 1<if((pins&pin)>0){pinactive = 1;}else{pinactive = 0;} if(ECAT[0].IO[ionum].data==1){ if(pinactive==0){ Gate3[0].gpiodata[0]=(pins|pin); //sets pin to high without altering other pin values. } }else{ if(pinactive==1){ Gate3[0].gpiodata[0]=(pins&(~pin)); //sets pin to low without altering other pin values.// evil hack because bitwise not is not supported. } } close

I am getting errors in the IDE when using bitwise not operators to make bitwise masks for use in setting GPIO pin outputs. I was able to work around the issue with a bit of an evil hack (4294967295^pin) instead of using (~pin). Is that operator not useable in the plc or do I have a bug that I'm not seeing? Full program follows: open plc 1 local pins = 0; local pin = 0; local notpin = 0; local pinnum = 0; local pinactive = 0; local ionum = 0; //This PLC is intended for reading limit switches and setting the appropriate GPIO pin high if the limit switch is active. ionum = 0; pinnum = 0; pins = Gate3[0].gpiooutdata[0]; pin = 1<if((pins&pin)>0){pinactive = 1;}else{pinactive = 0;} if(ECAT[0].IO[ionum].data==1){ if(pinactive==0){ Gate3[0].gpiodata[0]=(pins|pin); //sets pin to high without altering other pin values. } }else{ if(pinactive==1){ Gate3[0].gpiodata[0]=(pins&(4294967295^pin)); //sets pin to low without altering other pin values.// evil hack because bitwise not is not supported. } } close

I have not tried isolating it as a slave. The PDO I am trying to map is a 32 bit signed integer.

Hi I got a similar problem here: my ethercat chain is composed of 3 EL5032 (Endat 2.2 interface) and 1 EL3208 (8 channel input RTD). I can correctly configure the EL5032 but not the EL3208: it stays always in Pre-op conditions. However, I can correctly read the temperature via terminal and via plc using the ECATSDO command. My workaround: since I need the temperature information on a very slow time scale, I fire a PLC that perform the temperature reading via ecatsdo every 10 seconds. The major drawback of this solution is that the running time of this PLC is very high: I get a background load of +10% when this PLC is running. However, I can survive with that. Hope this helps best gigi Thanks gigi, I was considering doing that, and if it works for you I'll give it a shot.

System: PowerBrick AC running kernel 2.6.30.3 EtherCat Devices: 0) Beckhoff EK1100 LAN (works great) 1) Beckhoff EL1008 Digital Input (works great) 2) Beckhoff EL1008 Digital Input (works great) 3) Beckhoff EL3314-0010 Analog TC (doesn't work great, as explained below) When attempting to configure the EtherCat master on the DeltaTau using the PowerPMAC Suite, I am unable to get the temperature sensor readout to be placed in an IO register. (specifically ECAT[0].IO[0]) The problem appears two-fold. 1) When ECAT[0].Enable=3 is set, the Beckhoff 3314-0010 module does not transition to the OP state. However, if the states are set through the command line ethercat interface, the states transition correctly. root@192.168.0.200:/opt/ppmac# ethercat slaves 0 0:0 PREOP + EK1100 EtherCAT-Koppler (2A E-Bus) 1 0:1 PREOP + EL1008 8K. Dig. Eingang 24V, 3ms 2 0:2 PREOP + EL1008 8K. Dig. Eingang 24V, 3ms 3 0:3 PREOP + EL3314-0010 4K. Ana. Eingang Thermoelement (TC), hochgenau root@192.168.0.200:/opt/ppmac# ethercat states OP root@192.168.0.200:/opt/ppmac# ethercat slaves 0 0:0 OP + EK1100 EtherCAT-Koppler (2A E-Bus) 1 0:1 OP + EL1008 8K. Dig. Eingang 24V, 3ms 2 0:2 OP + EL1008 8K. Dig. Eingang 24V, 3ms 3 0:3 OP + EL3314-0010 4K. Ana. Eingang Thermoelement (TC), hochgenau 2) The PDO for ECAT[0].IO[0] should be set to the value from 0x6000:11 on the EL3314-0010. I have been unable to find a reason why the configuration steps that allow reading the EL1008, do not work on the EL3314-0010 However, when the value is pulled from the device using the command line ethercat interface, I get the correct thermal readout from the configured thermocouple: root@192.168.0.200:/opt/ppmac# ethercat -m0 -p3 -t int32 upload 0x6000 0x11 0x00000961 2401 (this reads as 24.01˚C) Attempted solutions: 1) setting startup variables: 0x8000:2 to 2 (for 0.01˚C output) 0x8000:19 to 1 (for J type thermocouple) 2) setting all PDOs for Device 3) "updating" to older versions of the device xml file. 4) resetting and reconfiguring both the PowerPMAC and EtherCat devices innumerable times. 5) reconfiguring the EtherCat Master multiple times 6) rescanning devices on the EtherCat both via command line and through the PowerPMAC Suite. 7) trying a newer version of the EL3314-0010 device. So, at this point I'm running low on ideas. Is this a known issue? Are there any solutions/workarounds that exist? Would I be able to run a plc to set up and query EtherCat values command line style rather than relying on the EtherCat system setup GUI? Any and all help greatly appreciated. _ Austin Kootz

The issue has not yet been resolved. Both the IDE and the Power Brick AC have been incrementally upgraded to: IDE: 2.2.1.25 Power Brick AC: 2.1.1.3 The Plot window has the "Gather Data" and "Upload Data" buttons greyed out. When "Selected Preset" has a name entered, (I'm using "CryoNIRSPTest") and the "Save" button is clicked, the following error message is returned: "Read Gather Data Failed. Likely mismatch between Plot and Gather Settings. Regather Data" Then switching to Legacy Mode: The "Gather Data" button activates, and can be clicked. The green bar fills over what appears to be the correct amount of time (~10 seconds for our settings). HOWEVER, when the "Upload Data" button is clicked, the screen appears to hang with the windows 7 busy circle spinning. The hang has lasted as long as I've left it, beyond 2 hours at one point. The GatherFile.txt file exists in /var/ftp/gather/ and it appears to contain the data listed in the window under "Step 2 - Data To Sample" Is this a known issue? If so, how should I fix it? We are beginning our Factory Acceptance Test process for three sets of these instruments, and this is about to start slipping our schedule's critical path. Any help you can provide is greatly appreciated, and I'll be emailing this to you directly to make sure we can talk with minimal delay. p.s. The Scope which functioned prior to the update has stopped working as well. I'm assuming the issues are related, and the scope is less important than the Plot tool.

Many thanks Steve!

TLDR: There are two versions of firmware 2.1.1.3 on the file depot. Which should I use for a 4 axis Power Brick AC? NON-TLDR: The IDE version 2.2.0.39's gather function fails when used with a Power Brick AC running firmware 2.0.2.14. It posts a waring about a legacy mode, then hangs when trying to upload the gather to the IDE. Cutting the gordian knot for that problem would be to update the Power Brick AC's firmware. The file depot has two variants of the firmware listed: 1) "2.1.1.3 powerpmac460ex" and 2) "2.1.1.3 powerpmac465" Which of these should I use? It is imperative that I do not brick the Power Brick AC. _ Austin Kootz