Gregs

I don't know if there are instructions for that, but I advise following the step by step setup instructions in the Geo Brick LV Users manual, or perhaps using those to supplement the setup software.

Try setting PowerBrick[0].MacroModeA =$808000 on the Slave. Copied from the Power PMAC User manual: Slave IC An IC used as a slave on the ring, as in a Power Brick drive used as a slave device, should have bits 12 and 13 both set to 0 to disable any master functionality. Bit 15 should be set to 1 to lock in the IC’s phase clock on receipt of the sync packet. Bit 23 should be set to 1 to disable the “master-number check” on the Node 23 packet. This means that Gate3.MacroMode should be set to $808000 for this IC (Node 15 master-number check disable, sync packet receipt lock).

I did a little research and found this info: Thread is a communication channel. For example, a socket can connect to a server from the command in a terminal window, or in a PLC. A terminal window is a communication thread, and a PLC is another one. Several sockets can be opened from a single thread. In principle, a socket should be opened and closed within the same thread. I did a little testing with a Power PMAC client to a Power PMAC server: I found that I could use the same socket with the Terminal Window and a PLC. I could connect to the server with either thread and then send commands thru both. Your issue was reproduced when I connected with the Terminal Window and sent a command from there before enabling the PLC. In that case, the PLC failed to send commands, and the connection closed (Modbus.State=0).

I don't remember all the details, but I know there is a problem with connecting in the Terminal Window versus in a PLC and mixing operations. The Terminal Window and PLCs operate in different threads, and that can cause conflict. Try doing everything in one or the other, and we can go from there.

What is the Sys.ServoPeriod setting? At what stage of operation does the error occur and how often? Did you try to clear the error with the CLRF or macrostationclearerrors {station#} command?

It sounds like you are using an old Turbo PLC, converted for Power PMAC, and the acceleration settings are not converted properly. The PLC I am thinking of has code that progressively scales the master position, i.e. handwheel, in order to slew the follower, i.e. controlled axis, up to the speed of the master. That will have an affect on the position scaling of the handwheel which will be aggravated by improper acceleration settings. There is a robust and proven PLC for Power PMAC that I can provide if you are interested. Just email to ODT-Support@omron.com.

No, TCP uses IP address rather than unit ID.

There is no way to change this in Turbo. That functionality was never added probably because Ethernet uses IP addresses for identification. In case it matters, it looks like it can be done with a Power PMAC (using Modbus[x].Config.UnitID).

Whether using the ACC-28E or 36E, their hardware reference manuals have Turbo setup sections that describe how to setup unipolar inputs and assign as servo feedback. Defining an axis in PEWIN can be done in the Terminal Window or in the Coordinate System setup window (from under the Configure tab). See in the Turbo Software Reference manual under the description for #{constant}->{axis definition}. If you are working with a CNC software application, the definition should be done within that software, at least for with any Delta Tau NC software.

I think the problem could be in ACC-24E2A setting SW1-2 = ON because that is a MACRO Station setting. Try setting: 6 5 4 3 2 1 Card 1 on on on on on on (Base Address $78200) Card 2 on on on on on off (Base Address $78300) Assuming the firmware is 1.937 or higher, E13 is normally on 2-3 on all ACC-24 cards, and then at re-initialization (either $$$*** command or power up with E3 jumpered on UMAC), the firmware will know that all of the cards are in the auto configuration setup and will assign the card with the lowest base address setting (usually $78200) the task of sourcing the clocks by setting variable I19 to the appropriate register.

I don't know of another way. Generally, PMATCH should not take longer than about 5 milliseconds. It does not perform additional tasks that would slow it down. Is there a Dwell 0 command before and after the PMATCH commands (longer Dwells could be reduced to DWE 0). Also, note that PMATCH is not needed if the position following is in offset (not normal) mode. Anyhow, your alternate method should be OK.

No Biss C. These are the current options: Feedback Options 0 = No options, Default; Standard feedback per axis is quadrature differential encoder with hall effect inputs or SSI absolute encoder . 1 = Analog Feedback including : • Option 0 Standard Feedback • 4096x Sin/Cos interpolator • Resolver Interface 2 = Absolute Feedback including : • Option 1 Analog Feedback • Endat™ • Hiperface™ However, a Biss C option is not unlikely in the future.

"PC Version" refers to PMACs with an ISA bus interface. Interrupts are used with ISA and PCI bus type PMACs. Clippers are Ethernet/USB PMACs and so do not use interrupts.

Hopefully this is better late than never. Using 2 UMACs, one as client and one as server, I am able to receive float data that is sent in IEEE 32 bit float format. For instance, 00111111100000010100011110101110 is roughly 1.01. I broke that into two Modbus registers and converted into decimal: 0011111110000001 = 16527 0100011110101110 = 18350 M1->X:$10780,16 M2->Y:$10780,16 M1 = 16527 M2 = 18350 I set up Modbus with FC16, Modbus Ref#0, PMAC Ref#0, Count length 2. Then, on the Server: M1->F:$10780 M1=1.0099999905 PMAC reads in using big endian format, so maybe you need to either convert to big endian or rearrange the byte assignments in PMAC.

See under "Using the JHW Pulse and Direction Outputs" in the 16-Axis MACRO CPU User manual, online under Manuals / MACRO Control Systems / MACRO 16 CPU.

I believe you could achieve what you want by setting Motor[x].PosReportMode=1 and setting Motor[x].HomeOffset for the right reference setting.

The only way I can think of would be to use a PLC. A PLC could check and modify the commanded position or TM at timed intervals. In order to maintain a consistent velocity, TM could be set proportional to the ratio of new to old position commands. Or, just limit the amount the position can change per time interval. However, for an easier approach, you might try linear mode which does obey Ixx16 and Ixx17, and then use only TS for acceleration in order to get a smoother profile approximation of spline mode.

The problem is that firmware cannot be downloaded to boards with OPT-16. The only way to make that happen would be to send the board in as a repair, which would cost $500+.

I got the suggestion to uninstall that Windows update and see if that fixes it. Should be under "Installed Updates" (Control Panel\Programs\Programs and Features\Installed Updates).

Look at the reported following error in the Following Error window when jogging. If you do not have that window open, it can be opened by right-clicking on the Position Window and selecting Following Error for Type. Set Motor[x].FatalFeLimit to a value greater than seen in the window, at least if it is an acceptable value. Better tuning might be what is needed to reduce the following error. I attached a tuning guide. Also, there are tuning guide videos on the website in the Video Center, from under the RESOURCES tab. Select "Traning/Tutorials". tuning primer.pdf

The question is what type of control signal(s) will the drive accept?

Did you go thru the Software Setup section in the ACC-72EX manual? Additional DeviceNet setup info can be useful or needed from a Hilscher manual. In Sycon.Net, you will need to load the EDS file for the Mitsubishi master. And in the Mitsubishi master (using their setup software), you will need to load the Hilscher slave EDS file.

I couldn't find the spec indicating a minimum for the drain-source voltage, just the 60 volt max; however, I was able to switch on and off 5 volts with a test setup. I used a variable power supply. Note that when I tried to go below 5 volts, it worked somewhat sporadically. It seemed to have trouble with only as low as 4.8 volts, although at times worked with about 1.5 volts, which makes the output LED very dim. And note that Delta Tau only supports 12-24 volts. That being said, I think that a strong 5 volt supply should work fine.

#3HMZ should work.

I think that I7104=20 is the problem. Unfortunately, in addition to setting the PFM pulse width, it sets PWM deadtime. The setting would have to work with other channels on the IC that use PWM control. What about the pulse and direction output on the Handwheel port? Is that already used?