mjm

We've verified the encoder signals using external equipment (as I mentioned in the original post). They aren't attenuating with velocity (within the encoder specification). The motor settings we're using for encoder loss detection are the defaults for a Gate3 device: pEncLoss = Gate3[].Chan[].SosError.a EncLossBit = 31 EncLossLevel = 1 EncLossLimit = 0 The board is a two channel type 604002 with options $41 and $50. The part revision is 7 and part type 1. Is there any filtering on the board that might roll off the signals? Mick

We seem to be having difficulty with the encoder loss detection of a sinusoidal encoder connected to an ACC24E3. The problem is related to velocity. We've verified the signals using an oscilloscope. With loss detection disabled, the servo is fine at velocities above which encoder loss is reported. I've looked for performance information in the ACC24E3 hardware manual, but can find none. Is this data available? Any thoughts would be appreciated. Mick

And it shouldn't alter file attributes. Mick

Surely only unsaved files need to be saved before a compile/download. I've used Visual Studio for many years, and it's never complained about read-only files when compiling. Mick

Yes, I consider this a major issue. We use Visual Sourcesafe for version control, and it relies on the read-only attribute. Mick

Why does the September release IDE remove the read-only attribute from files in the solution/project? It may be convenient for the IDE, but these are my files, and I should be able to decide whether or not they are writable. Mick

I'm not sure which header file is really important. Perhaps I shouldn't have mentioned it. My post was really to ask for the missing task params, task state and task info areas in the DPM of the Hilscher card to be accessible using the Acc72E[] Structure e.g. Acc72E[n].Task2State[0] mjm

Looking at the Acc72e structure members accessible from script programs, there seems to be missing members for task params, task state and task info. Looking in the header file where this structure is defined, these items are covered by a member called unused2. Can these items be uncovered in a future release. I can set up ptr variables to point to the missing data, but I have to do a considerable amount of manipulation to unpack the data I require, and I'm not sure it's desirable to use a mixture of access methods to this hardware. mjm