KennNova

Yes, mapping 0x6071 as a PDO will work. However, in order to make it useful, you will need a F/W update from ABB: 5862.0.10 WIP. This will provide a new parameter called Torque Ref Scale in the TorqueControl branch. This will allow you to scale the Motor[x].MaxDac to the maximum torque of the drive.

Macro.Status[0] in terminal window returns #20 Illegal command. Has it been replaced? Intellisense allows it.[/color]

Macro.Status[0] in terminal window returns #20 Illegal command. Has it been replaced? Intellisense allows it.[/color]

Very good...I was using the "Power PMAC Modbus Design Document" and that document did not have this info. Of course, I should check for a later document. Thanks for your help.

Thanks Charles. I actually worked on it more and have figured out where the problem is. For some reason, this particular function requires a "int" as an argument at the end of the argument list. Don't know why, but it is not consistent with what works in the terminal window and not consistent with what works for the ModbusFloatRead function.

Having a problem in a capp with Modbus. Error copied from the output box is: \\opt\eldk-4.2\debian_rootfs\opt\ppmac\libppmac\modbus.h(138,0): Error : too few arguments to function 'int ModbusRegisterRead(int, int, int, short unsigned int*, int)' The ModbusRegisterRead works fine in the Terminal, but in the capp, I don't understand what appears to be extra "int" arguments. Cannot find documentation to support the function as shown in the error code.

We are looking to use a couple of the output bits sent to an ABB FMAC-01 station at Gate3[0].MacroOutA[4][3]. It appears from the ABB documentation that bits 31,30,29,28 are unsed. However, when we attempt to write to that location, it is over written. We were actually attempting to point the brake control to that location, but that didn't seem to work either. We did find an undocumented pPMAC feature called Motor[x].MacroCrtl. It appears we can write to that location and the bits to flow through Macro to the FMAC-01 registers. However, pointing Motor[x].pBrake to Motor[x].MacroCrtl doesn't seem to work either. Better ways of doing this? Help!

Thanks Greg. The TTL signal level is a show stopper for us. 5 volt logic is pretty much useless in our market of industrial control. We'll have to go another route for the extra I/O we need.

We would like to use inputs on the Acc5E3. However, I cannot seem to find a typical input circuit diagram in the Acc5E3 manual. Nor can I find a spec on the sinking/sourcing voltage.

The power supply feed the UMAC rack was 24.2 volts from moment of power up. Are there easy places to measure the voltages produced by the power supply in the rack? This morning, the card stopped responding all together. The motor vibrated and would not tune. The CPU is reporting i²t faults. The motor runs fine from the drive. We installed a spare card from our development system and it performed as expected. We will swap the original back as a test, but first we will try a cold restart tomorrow morning. During all of this, the supply voltage to the UMAC rack was a good 24.2 volts.

The amp is a Copley Xenus rated at 6 amps driving a Parker linear motor rated at 3.8 amps. (Numbers are from memory, close but not exact.) I'll check with Copely to see if they have a start-up current spike. The drive is fed from 230, 3 phase while the pPMAC derives power from a 24 VDC power supply. We'll verify the level of the 24 VDC supply. We'll also monitor with a scope during an enable event. I don't understand your last question. There is no direct connection between the ACC24 and the drive except the command signal and the buffered encoder repeater. Are you talking about the input impedance of the Copley reference circuit? We are limiting the DAC to arround 18000 so that the motor is not subjected to over drive. Also, once we get the drive to enable, after being shut down for the night, we can enable and disable the drive all day long with no problem. We have only seen this on a cold boot after an extended (overnight) shutdown.

Having a problem with a pPMAC CPU and an ACC24E2A card. The ACC24 card powers up, but as soon as we try to enable an axis, the ACC24 shuts down...no lights. After a number on power cycles, and what appears to be blind luck, the ACC24 will survive an Enable command, after which it runs perfectly. The hardware is December 2011 vintage. End user mothballed the project for a year, so the system is in startup....has never run production. We updated the firmware in December 2012 when the project started back up. Rack has CPU, ACC24(1), DIO(1) and a 24DC power supply. We're using 2 sockets of Modbus. Any ideas? Our IDE rev is 1.5.0.21 and CPU Firmware is 1.5.3.0

I've downloaded all the files, but when I attempt to extract the *.zip archive, I get a message that the file is corrupt. I've attempted to redownload that file, but get the same response. Any ideas? In this situation you can download the non-archived version of the IDE.