JeffLowe

ACC-24PCI is a PCI bus form factor whereas the ACC-24E2A is a UMAC board. I did see an ACC-24PCI2 card listed in the product selector, but have no knowledge of the difference between that and the original.

Some of our original machines in the field are still at FW rev 1.6.1. We are currently at 2.1.1.3 for our production systems. How necessary is it to upgrade to each and every firmware revision in between? Is there a way to do this with a single USB boot stick?

In case anyone is still following this thread, The root cause of the amp enable relay failure has been determined. The gate driving the optocoupler was undersized for the current required. An ECN is in place to change this gate to one with a higher drive capacity and the current limiting resistor on the optocoupler was changed as well. Hats off to engineering for digging in this deep.

I have created the following background cplc for test. Upon enabling with UserAlgo.BgCplc[0]=1 I monitor the p variable testpvar and Sys.Idata[50000] in a watch window. The p variable increments correctly and continiously, but the variable accessed by pushm does not. Any ideas as to what I am missing here? // CPLCs/bgplc00/bgcplc.c #include #define _PPScriptMode_ #include "../../Include/pp_proj.h" void user_plcc() { int *sos_tmp; sos_tmp = (int *)pushm + 50000; // pointer to Sys.Idata[50000] *sos_tmp++; // increment for test testpvar++; // testpvar is declared as global testpvar in blobal definitions.pmh }

We have a customer that has received this error on an NC5 system. This error is not one of ours so it must have been generated internal to the HMI/PComServer. Any information on source and corrective actions would be greatly appreciated.

Thank you Curt for pointing out my error. A two point non-rollover comptable should have Nx[0]=1 for a single zone.

We are using both transformation/rotation matrix, and kinematics. Comp tables are more straight forward in my mind.

Trying to create a 2 element CompTable to correct axis squareness. The table is using CompTable[15].Ctrl = $4 This should be linear interpolation, non-rollover. The comp generated starts at zero, at half travel my full comp is being applied. It then diminishes back to zero at full travel. It looks like this is doing a mirror instead of holding the last value. Do I need more data points?

I was recently speaking with a potential encoder vendor on a BISS application who's product previously failed due to upper bit transmission failures. This was circa 2014. He informed me that there are firmware updates in the ACC84E that correct this problem. Can Delta Tau verify this and if this is the case, how do I get my older ACC 84E updated?

The one board with a visible crack in the solder joint was repaired and placed into production. I did not get a picture, nor was the serial number recorded. The remaining four boards are at Axis now being evaluated. They are all 1-2 years old and have been functioning normally up to the point of failure.

We have seen similar failures on Acc-24E3 boards: on the amplifier mezzanine card, the 'Clare LBA716 Dual Single-Pole OptoMOS® Relays Normally Open & Normally Closed' relays have failed. Most of the systems have been running for years without problems. J: How many boards have you seen fail? We are on 5 and counting. This failure mode has become very visible to a major customer (18 machines, and more pending) so I really need to find some answers. My contacting the chip vendor for reliability data on the board is just not appropriate.

I need to generate a normal angle to a contour. I am looking at using Motor[0] with a user written servo. The Motor[0] position will then be used by a came table for other functions. double user_pid_ctrl(struct MotorData *Mptr) { double normalangle; if (abs(Motor[XMOTOR].DesVel)>0 || abs(Motor[YMOTOR].DesVel)>0) { normalangle=atan2d(Motor[XMOTOR].DesVel,Motor[YMOTOR].DesVel); } else { normalangle = 200; }// not a valid angle use for table suppression. return 0; } Would it be appropriate to write the angle directly to Motor[0].pos, or should it go through an encoder table entry, or perhaps some other register?

[quote='NadirN' pid='11376' dateline='1534963754'] [quote='JeffLowe' pid='11373' dateline='1534853435'] [quote='NadirN' pid='11369' dateline='1534791473'] Hello, This is my first post to this forum, so please bear with me. I am using a Power PMAC firmware version 2.1.1.3 and IDE version 2.2.0.39. I am trying to use printf() and send() to debug a Background C application. The code below does not produce any output at the IDE Terminal Window or at the Unsolicited Window, even though I have enabled Buffers 0 through 7 and set the Control Properties to ActivateSendPort 0. Any help will be appreciated. Nadir #include // Global Gp Shared memory pointer #include "../../Include/pp_proj.h" int main(void) { int sendport; sendport = 0; Send(sendport,"Hello\n"); printf("Hello\n"); CloseLibrary(); return 0; } [/quote] The IDE terminal is not a Linux terminal. Use Putty to setup a Linux SSH terminal for your printf statements. Also, building a serial cable and running putty to the serial connection is helpful as this is the Linux error device. [/quote] Hi Jeff, Thank you very much for replying. I downloaded Putty and logged into Linux. I ran the compiled C app "myprint.out"(code shown below.) #include // Global Gp Shared memory pointer #include "../../Include/pp_proj.h" int main(void) { InitLibrary(); printf("Hello\n"); CloseLibrary(); return 0; } The Linux command line is: root@192.168.0.232://# /var/ftp/usrflash/Project/C\ Language/Background\ Programs/myprint.out The Linux response is: Segmentation fault root@192.168.0.232:/var# Any ideas? Nadir [/quote] InitLibrary(); // missing?

[quote='NadirN' pid='11369' dateline='1534791473'] Hello, This is my first post to this forum, so please bear with me. I am using a Power PMAC firmware version 2.1.1.3 and IDE version 2.2.0.39. I am trying to use printf() and send() to debug a Background C application. The code below does not produce any output at the IDE Terminal Window or at the Unsolicited Window, even though I have enabled Buffers 0 through 7 and set the Control Properties to ActivateSendPort 0. Any help will be appreciated. Nadir #include // Global Gp Shared memory pointer #include "../../Include/pp_proj.h" int main(void) { int sendport; sendport = 0; Send(sendport,"Hello\n"); printf("Hello\n"); CloseLibrary(); return 0; } [/quote] The IDE terminal is not a Linux terminal. Use Putty to setup a Linux SSH terminal for your printf statements. Also, building a serial cable and running putty to the serial connection is helpful as this is the Linux error device.

NC is a 32 bit application, it and any required files must fit in 1Gig. In our systems, this is some where around 750 MB. Larger part programs must be broken into M98 or G65 subroutine calls.

We are using the ACI with 0.250 um scales and they work quite well over the full velocity range of the scale without any filtering. If there are no improvements by applying the tracking filter it is likely the problems lay elsewhere in your system. At this resolution direct drive systems with low noise/low distortion linear amplifiers are usually required.

On the one card here I have here I found a dry joint on one of the legs of the gull wing package. A parting line was clearly visible under the Mantis. Probing the pin easily lifted it away from the pad. Possible causes clogged stencil, insufficient paste since this is near the edge of the board, or un-level pins on the component.

Three times in the past few weeks we have had failures of the Amp Enable on the Acc24E3 cards at three different customer sites. These are operating Glentek and Trust drives, both at TTL levels with internal 10k pullups to 5V. These machines have been functioning normally for periods up to two years. Are these physical relays, and if so, what is the MTBF/MTTF?

Acc24E3 with 18 bit DACs. Non-commutated torque mode motor, Phase =16, servo =8 KHz. We are experiencing a 2.5 Volt, 62.5 usec wide glitch. This can be captured with an oscilloscope, but Gather of Gate3[0].Chan[3].Dac[0] does not show the glitch, only the aftermath (Ringing in following error and the proper servo response to it). Can this be the result of clock settings, and If so, what are the recommendations?

I can see that 2016a is the most recent version supported, but I am looking at what tools are needed, it Matlab, Simulink, Control systems toolbox?, other toolboxes? Which coders? (Matlab, simulink embedded coder?) I am hoping that someone at Delta Tau can give me a basic shopping list.

I am curious about the minimum Matlab/Simulink tool set to generate user written servos for the Power PMAC. Anyone have a list, and do the latest versions work with PPMAC? Thanks

Is it possible to setup an encoder table entry sourced by the 64 bit floating point value pointed to by Motor[x].CompDesPos.a? I know .DesPos.a is possible, however I am trying to track a cam table transparently which drives Motor[x].CompDesPos.The resulting EncoderTable Entry would be used in Motor[y].pMasterEnc.

This switch does not exist on the new flash piggybacks.

We are trying to use a boot recovery stick ( a USB stick with a folder PowerPmacFirmwareInstallandConfigLoad with the .deb and the usrflash folder in it) to recover a customer in the field. The previous notes in the forum refer to a setting the write enable switch on the flash piggyback. Our current CPUs have no such switch. The manual in the file depot is dated 2009 and includes nothing about the options and the current flash boards with the micro sd cards. Is there an updated version of the manual that covers options and changes made in the last decade? (I hate writing manuals too, so I do understand)

Unfortunatly, dwells and CoordSys readieness relies on an and of all axes in the CS. Is there any way around this?