tecnico

I faced a similar problem twice with a heidenhain sincos encoder that was used in a UMAC with Control Techniques SLM system (the encoder was sampled and converted in SLM format with some dedicated adapters) and both the times I could see huge spikes on the actual position. And both times the system had power supply problems, so check for noise in the power supplies Ciao Andrea

These are the results of the HallUVW utility, repeated a few times with the same result. It looks the only motor with the correct phase setting is #2, (ix91 is $CB0000 for all motors), while motor #3 (Z2) has about 5° and #5 (Z3) about 30° shift. I can't believe that a 5° shift can cause a runaway while a 30° shift doesn't.... any ideas?

The problem only occours at the very first phasing, so it looks unlikely that the encoder is missing counts. However, I will ask to make the test. I appreciate the suggestion for fine phasing, I will look into it for the future.

I've already sent the tool, as suggested also by DT Europe. I'm waiting for a reply, but my aim is also to understand what's going on. Another identical application is not running into these issues so I was wondering what could cause the runaway. So far the possibilities are: - bad/intermittent contact in the hall sensors feedback / hall sensor close to failure - encoder that slips on motor shaft (but doesn't seem the case) - other ideas?

Hello, I have a customer that is experiencing some problems (occasional runaway at first movement) with commutated motors (using a GeoBrick), hall sensors. Since I'm not there the best I could do is to make him plot the hall sensors U V W values vs the phase position. All the motors should be mechanically phased. the ixx91 value is $CB0000 for all the axes, that inverting the formula means that HEZ (Hall Effect Zero, transition from 3 to 1) point is expected at 61.875 degrees. The motors are named Z1,Z2 and Z3; Z3 was recently changed because of a defective Hall sensor. Z2 is the one giving troubles recently. Looking at the plots I can only see that the Z3 seems to have roughly a 20° error (but it is not the one having problems)... Any suggestions on what else should I check? Z1.pdf Z2.pdf Z3.pdf

Hello all, the freeze problem turned out to be related to the "unsolicited messages" (e.g. ERR00x that we sometimes see on the pewin32Pro wondow) that were not handled by the HMI and, after some time, filled the communication buffer causing the PMAC to freeze. Connecting with Pewin32Pro2 causes a flush of the buffer, making the PMAC functional again. So you need to either make sure that you don't get those messages or to flush the communication buffer from time to time. Side note: a similar problem was happening on a grinding machine (based on a ADV400 system, connected via USB). Here, probably for noise /spikes , the USB commmunications fails from time to time and the machine "freezes". If I take off the USB cable and connect to the PMAC with another PC the machine starts over and finishes the job.... Also in this case leaving the Pewin32Pro open (minimized) seemed to be a patch for the problem.

I would check the value of the output register of the DAC (m102 in the suggested variables), the encoder feedback (does the PMAC see the motor moving?) If encoder feedback is working and the DAC register is giving some output you should see the output voltage reflect the DAC value (32000 should be about 10 volts). Another factor could be i269, that sets the maximum DAC value allowed. Note: all these tests shoud be carried out following the safety rules

Hello, unfortunately the ethernet "driver" for Linux doesn't include anything about Binary Rotary buffer. I am working on a application that streams data on a GeoBrick through binary rotary buffer in Windows environment, but since the data source is a Linux based PC we would like to skip the Windows gateway and its added delays. I searched a lot but I couldn't find any documentation about the ETH commands for binary rotary buffer (the documented OP codes in the ACC54V2 manual stop at C7 but if I'm not mistaken binary ROT has code C8). Searching also in the DPRAMOPT.PDF document, at page 34, i read this sentence: " Note: Delta Tau has PC subroutines written in C to interface with the DPRAM binary rotary program buffer. Contact the factory for details." , so I guess there is some documentation I don't have. Thanks for your support

While working on the field with these encoders I had to face another issue: since the source encoder is a 3m long MLDT transducer with base resolution of 200 cts/mm I was forced to scale down the resolution to avoid the rollover in the ECT. This doesn't happen with a 1100mm long transducer. So what is the practical limit using a single entry of the ECT? I would say 8388608/32= 262144 but a confirmation would be appreciated...

Hello, I'm working on a plant with 3 Pmac2/PC104 racks, all connected to the same PC; 2 are connected with Ethernet and one with serial (since I need the DPRAM on ACC2P). Each PMAC has its own HMI, communication server is PCommServer (Pewin32Pro2). One of these PMACs (with Eth) showed a pretty strange behaviour: while working one of the axes executed the "end of cycle" movement in advance (but the others didn't) but, worst of all, the machine stopped responding to commands. I connected with my laptop to see what was going on and as soon as I established the communication the machine started responding again.... This thing happened twice, and while the anticipated end of cycle could have been triggered setting a variable to zero (but can't understand where) what is really puzzling is that the machine resumed from "freeze" state just by establishing a ethernet connection. Another problem I have is that from time to time the PCommServer on the HMI crashes without apparent reasons. The ethernet network at the moment is shared with other devices, and there is a server on the network that sends "Attacks" according to my Norton Internet Security "OS Attack: MSRPC Server Service RPC CVE-2008-4250" Will try isolating the machines from the external network, but I wonder what could cause such problems Regards Andrea

Hello, this explains why, to make the ADC work in a setup with no 60 poles cables connected (just for tests) I had to close jumpers E85 and E87 (e88 not needed since the ADC take -12V directli from the bus). I wonder why this choice to tie the ADC to AGND forcing the customer to connect GND to AGND thus defeating the isolation.... BTW the inputs look pretty noisier than the ones on the "old" ACC-36. Can this be related to the fact that at the moment the link between AGND and GND is made externally (on the 60 poles terminal blocks)? Would it be better just to close E87? Or might it be an effect of the defeated insulation? Out of tree boards I managed to have 2 working (even if a bit noisy), the last one (the one with OPT12A) only replies with 4095 (or 2047 if I call for bipolar conversion). Even putting it in the same environment of the good ones doesn't give results, so I'm afraid it's faulty...

Update: after further checking it looks like a ground problem. The tests in my lab were made providing analog power supply from the bus, while on the plant analog power is external and isolated (E85, E87 and E88 are OFF). According to the manual this shouldn't be a problem (it clearly states that ANAIN GND is not isolated from digital) but testing the board I found it only tied to AGND; moreover on JANA there is a +/-12V output that comes from the bus but the power supply for the ADC is again tied to analog supply voltage.... Testing for voltage on the field I found that in the machine that works fine AGND is tied to DGND but in the "bad" one I read about 1.2V difference. At the end it seems that the only option is to connect AGND and DGND, but I would like a confirmation from those who actually have the schematics and have designed the product.

Hi all, I have a very strange problem with OPT12(A) of Turbo PMAC PCI. I'm installing 3 of these boards as a replacement for the older Turbo PMAC PC (ISA BUS). The old boards were acquiring analog signals through ACC-36P, but now we rely on OPT12(A) to get those analog inputs (even if they accept 0-5V instead of 0-10V). I followed the instructions on the manuals and I got to this configuration for the automatic A/D processing ring (0-5V setting): I5060=8 ;line 13 I5061=$78808 I5062=$78808 I5063=$78808 I5064=$78808 I5065=$78808 I5066=$78808 I5067=$78808 I5068=$78808 I5081=0 I5082=$1001 I5083=$2002 I5084=$3003 I5085=$4004 I5086=$5005 I5087=$6006 I5088=$7007 After succesful tests in my office I went on the field... The first machine runs fine, but the others give me random numbers (most of the times 4095) on the converted analog inputs. Since the software is the same I'm a bit puzzled....it looks like the processor can't access the ADC or that the conversion can't be triggered... Any hint? Andrea

doing other tests I found my mistake - I forgot changing position and velocity loop address. Since the encoder conversion table is now shifted from the standard I was erroneously pointing to the intermediate value before shifting.

I'm using Profibus MLDT sensors to close the loop to some hydraulic axes. To do so I get the encoder position from profibus and put it into a 24 bit register e.g. m1000->X:$772,0,24,S Then I set up the Encoder conversion table to get the data from "Parallel pos from Y/X with filtering" (but actually I tried also from Y and without filtering). The Issue that I have is that the ECT doesn't correctly apply bits shifting, so regardless of the setting I get 1/32 of the value in M1000 as position counts. so if M1000 equals 10000 I get 312,5 cts if I set "Normal shift (5 bits to the left" and also if I set "No Shifting") Macro Shifting gives a different result. I know I can get away multiplying the source value by 32, but I was curious to know why those setting don't work. P.S. Reading the ECT I can see that the setting is actually different ($700772 vs $780772) P.P.S I use a 80MHz PMAC2 - PC104 Any ideas?

I have troubles communicating with a Pmac2A/PC104 through Acc-2P. I am able to program the IP address, the card replies to ping (both from Pewin32Pro2 and "dos" command) but refuses to communicate. The CPU is a 80 Mhz 5CF option. Since I have another identical CPU (with opt12 added) I tried with this one and.... this way it works, so it's not a fault of the ACC2P. I tried resetting the card with E3 jumper with no result. Swapping the CPUs I noticed that with the "bad" one if I plug the USB cable with the PMAC already powered windows says that the USB device could not be recognized, but if I power the device with the cable already inserted it is correctly recognized (tough it doesn't communicate through USB or ETH) Any hints? Both boards are new, assy 603670-109