gmschoon

On several of our ACC24E3 cards (Endat serial encoder) we are getting CRC & error bits (E0, E1) set in "SerialEncDataB". The errors appear to occur randomly on different cards and channels (we have 14 channels in use, 4 of which show errors) and persists for period of time from 5-45min after power on (from cooled down state). If we issue the "hmz" command, the result is incorrect and different from when the error is not reported (perhaps unsurprisingly). We have the following configuration for the Endat 2.2 serial encoders. Acc24E3[n].SerialEncCtrl = $1000003 (this is directly from the Acc24E3 manual) Acc24E3[n].Chan[n].SerialEncCmd = $71419 Based on the behaviour it seems that the issue relates to temperature, however it is not clear what is causing this as there is really just the serial encoder and ACC24E3 involved in the loop. Any suggestions appreciated. Thanks

Hello Steve, since we experience the same problems (though I've learned to live with them *sigh* ) I can tell you, that these problems most likely don't connect to those settings. If they were connected to these settings at the PCs end, it would mean, that other PCs could still connect to the PMAC, right? I've checked with many PCs connected to the same network as the PMAC while the PLCs were running. But I could not connect from any machine to the PMAC, while it was in this condition. So there are two possibilities: 1. Those mentioned settings are at the PC end, but break the ethernet at the PMAC (sounds unlikely, but would be an interesting solution, I'll try) 2. something else on the PMACs end breaks, and is not connected to the energy settings. @gmschoon: For a little help until there is a solution try the following: 1. extend in the project settings the projpp timeout time 2. set the Sys.BgSleepTime to a value greater than 1000 (default at 0 is 1000usec) at least while uploading a new project verison this helped a lot regarding "time needed" and "pmac broken, need to pull the plug" Greetings, Georg @Georg: Thanks for the tips, we will implement the suggested changes to reduce lost development time, however the more worrying bit is having connections drop when the PMACs are networked with our higher level controller. @Steve: While energy efficiency settings could potentially cause a dropped connection, what we are seeing is an ethernet port that then seems to become unavailable until the PMAC is power cycled. Has the r8169 ethernet driver changed recently and is it managed in any way by Delta Tau? Are there config options for the r8169 if the driver is compiled on the system? Perhaps there is an upcoming firmware release to address this? Thanks

We have an issue with PMAC where the ethernet socket becomes unavailable for new connections, requiring power cycle to connect. Setup: - PMAC 465 - Firmware 2.4.0.180 - IDE 3.1.2.2 - rticplc, bgcplc running The issue appears to correlate with incoming data/connections to the PMAC, and has been observed in the following scenarios: - Build and download, fails during build process as well as during load process - When sending commands to the PMAC - Attempting to launch plot tool (throws error after trying to connect) In all scenarios when the issue(s) occurs the following are true: - Cannot connect IDE or if IDE is still running, cannot establish any new connections (terminal, watch, plot, etc) - No response with ping - Cannot SSH - rticplc and bgcplc continue to run and any active windows (watch, position, etc) will continue to display live data. Any suggestions welcome.

For our application we are not too bothered about the larger filter time constant, but rather need as clean a velocity signal as possible. Part of what we are unsure of is what the difference might be between the tracking filter (index2 set to max 255 and all other index=0) for a resolver and the same tracking filter used for a sinusoidal encoder. We have been using the tracking filter with index2=255 for some time with a sinusoidal encoder which goes through many more cycles per motor mechanical revolution than the resolver, without issue. From the manuals it appears that we should be able to setup the resolver in the same way as the sinusoidal encoder, however, the result we see in .ServoCapt or .TimerA is not the same (sawtooth for the resolver and a nice ramp for the sinusoidal encoder as detailed in your response).

AtanEna = 1 TimerMode = 0

We have encountered a problem with filtering of the resolver position feedback. We have the following configuration for a 4 speed resolver (as per snaps attached). Enctable[18].pEnc = ACC24E3[0].Chan[1].AtanSumOfSquares.a Enctable[18].type = 1 Enctable[18].index2 = 255 (max value for 1st order filter) Enctable[18].ScaleFactor = 1/2^16 This configuration results in the attached snap, where "Motor[2].Pos" appears to move backwards slightly periodically while the motor shaft is being rotated consistently in one direction. This only happens when the motor is rotated at a sufficient speed. When we do not use filtering (i.e. index1 = index2 = 16) the position reported as we rotate the motor is as expected and increments consistently in whatever direction the motor is moved. Also of note: As far as we can determine from the manuals, we should be able to point "pEnc" to "ServoCapt" as this is the configuration used for sinusoidal encoders and other than slightly different interfacing hardware on the ACC24E3 variants it should be the same at the register level. When we look at "ACC24E3[0].Chan[1].ServoCapt or ACC24E3[0].Chan[1].TimerA" we see a sawtooth response that has a 16 bit magnitude (see trace in attached snap), far from what we would expect. Any comments appreciated...

We are trying to setup data packing for an application and have the following configurations, using firmware version 2.4.0.180. Setup 1 for data packing (step 1 of motor test/commission window shows Adc0 responding as expected, but Adc1 is fixed at -16711936 which suggests the data is being packed but not interpreted correctly): PackOutData = 1 PackInData = 2 PhaseCtrl = 1 Setup 2 for data packing (same result as above): PackOutData = 1 PackInData = 3 PhaseCtrl = 1 Setup for unpacked data (works as expected): PackOutData = 0 PackInData = 0 PhaseCtrl = 4 We may be able to proceed using unpacked data, however if someone can point out any config settings that may have been missed it would be much appreciated. Thanks

For on-line commands is there any difference in how the command is handled (ignoring execution priority/scheduling of the thread it is initiated from) between a plc and a cplc? For example using 'adisable' directly in a plc routine vs using 'Command("adisable")' in a bgcplc or C app. I also note that gplib.h states: "These functions are for use as an API for linux "C" APPs. \warning They are NOT available to user written real time "C" PLCs." Presumably this warning pertains only to the RTI driven cplc and use of "Command()" is ok for bgcplc routines. Thanks for any clarification

This seems to happen when a fresh install of the IDE does not yet have the relevant compilers installed, and expects to find specific files/folders for the build process. You can either navigate to the Installers folder in the PMAC install directory & launch the compiler setup.exe for your hardware or connect to the PMAC hardware to trigger the compiler install process.

We have a similar issue with 4.2.0.13 fresh install on a clean Windows 10 (256 GB SSD) build. MySQL fails to install tables (error 1). Tried following the suggested fixes, however it appears to be failing at an earlier stage in the process and as such deletes the ppmac4.ini (as per log below), as part of the failed install cleanup. "1: Custom Action: The 'Install_PPMAC_MySQL_Files' batch file failed (error code: 1) 1: Custom Action: Entering 'RemovePMACMySQLDataFiles' function 1: Custom Action: Deleted 'ppmac4.ini' from C:\Program Files (x86)\MySQL\MySQL Server 5.0 ... CustomAction Install_PMAC_MySQL_Files returned actual error code 1602" Based on the nature of the issue, we thought the quickest way to resolve this might be to create a new partition on the SSD, with sector size that MySQL 5 tables will be happy with. Any suggestions appreciated...

In the ACC24E3 user manual, page 100 suggests that ALTCOS & SIN can be read via Gate3.Chan[j].AdcEnc[2] & [3], with no automatic calculations performed, however page 52 & 53 suggest that the closest (of 8 options) we can get is to have raw A/D data for SIN/COS by leaving Gate3.AdcEncStrobe as default or "&" to clear. Given that we want to have ALT COS & SIN signals in Gate3.Chan[j].AdcEnc[2] & [3] registers, which section in the manual is correct? Thanks for any feedback

Trying to implement master/follower with follower position compensation for a dual motor control driven gear (two worm gears driving main slew ring). Presently, the setup has the two motors driving in opposite directions with motor 2 following motor 1 trajectory. This works fine, however we want to offset the position of the follower (motor 2) relative to the master (motor 1) trajectory based on a cam/comp table. // present relevant configuration Motor[1].ServoCtrl = 1 Motor[2].ServoCtrl = 8 CompTable[0].Target[0] = Motor[2].CompDesPos.a The correct value based on the table and position of the master is written to the "Motor[2].CompDesPos" register as expected, however "Motor[2].DesPos" does not reflect this offset. It appears that for master/follower (ServoCtrl=8) mode, the master trajectory is applied directly at "Motor[2].DesPos" (or some point further) in the attached diagram and ignores offsets applied by comp tables. Is it possible to apply a comp table while having a master/follower configuration or is it necessary to apply servo loop cascading settings (Motor[x].MasterCtrl) to achieve this? Thanks

Thanks for pointing to this datasheet. Presumably the voltage levels are consistent between the Power Brick LV & ACC-24E3 resolver cards?

Bit of a late update, but I think the root cause was failing to properly close/clear buffers before attempting to write. I have not had any problems since and precede all motion program char strings with "close"... Command("close &1 ..."). I am also clearing all axis definitions with "undefine all" before creating new associations. However, it seems that the motion buffer cannot be opened and filled over multiple consecutive Command(), but instead requires that the prog buffer be opened, filled and closed, all in a single Command() call. I am not sure how the command parser sees the string sent via Command() or GetResponse(), but I had thought this would be similar to the terminal; allowing the prog buffer to be opened, filled over multiple commands and finally closed. Any insights are much appreciated. Thanks

Bits 23-22 of Gate3.ResolverCtrl define the resolver excitation gain for an output that is a function of "full magnitude", however we are not sure what the actual full magnitude voltage is. Before we try and probe the outputs with representative loading, does anyone know what the full magnitude voltage of the 24E3 outputs is? Thanks