zros

Try changing the protocol in the URL to: "ftp://support.deltatau.com/DT-USA/milici/PPMAC%20IDE/HELP%20FILES" This URL string worked for me (do not include the double quotes that I added) - the forum software (MyBB) is automatically adding the http protocol stuff, so it would appear. Thanks Steve.

Yes - the case on the 't' in type was the difference. Thanks. I have looked for the C API help, but I'm coming up blank as to where to find this. I don't see it anywhere on the online help through the IDE. And numerous searches of this forum just say - "its in the example projects". Which example, and how am I suppose to access the documentation? I'm stumped as to where this at, specifically. If there is a PDF document with the API for download - I haven't found it. Thanks.

Without checking I am guessing that it is complaining that you have not assigned the left-shifted value to anything. Maybe temp_byte = rRange200y; newtemp = temp_byte <<; ...

I am trying to implement a triggered time base application very similar to the example given in the training class, but with arming the time base in the CaptCompISR function instead of a PLC. (BACKGROUND: The application receives an external signal to arm the time base and the trigger event signal is also from a motor that the PPMAC does not control. Furthermore the arming event is not synchronized to the triggering event by the external system. Therefore the time from external arming signal to trigger can be extremely short. By using a RTICPLC (for example) for arming the time base, my probability of missing the 'first' triggering event is greater than 2000x more likely than if I can arm the time base inside the ISR.) The issue I'm running into is that I need to check the status of the EncTable[x].Type within the ISR to verify that it is set to 10 (i.e. a frozen time base). However, I haven't found a way to access the type register for EncTable[x] in C code. Inside the ISR I have tried: if(pshm->EncTable[1].Type == 10) pshm->EncTable[1].Index1 = 3; but this generates a build error 'struct EncData' has no member named 'Type'. A post from 2014 indicated that accessing the encoder table in this way causes problems (http://forums.deltatau.com/showthread.php?tid=1635). What's the best way to access the type register for a given encoder table entry in C code?

I tried the rename, clean, build and download all sequence without success. I'm seeing similar results as before. I also created a new plc (one that has never been used in this project) and named the buffer straight away to 'myplc23'. open plc myplc23 .. .. close This also generated the error when I did a 'clean, build and download all' sequence. Just to be clear - it is the buffer name that needs to be an alphabetical name for debugging inside the IDE and not the module name, correct?

I am attempting to debug a script PLC through the IDE. I found a thread from 2014 (see http://forums.deltatau.com/showthread.php?tid=1681) that indicated the you must use a non-numeric name for the buffer instead of a number 0 - 31. 1) Is this still true with IDE version 3.1.1.0? When I named my plc buffer to a name, e.g. myplc31, then the download process always throws an error indicating that whatever buffer comes after the 'named' buffer is in use. For example, I re-defined the start of my plc 31 from: open plc 31 .... close to open plc myplc31 ... close and upon either a 'build and download all' or 'download selected file' I get: Error : ( Preprocessing Error) PLC in use, already auto-assigned : on string ("open plc 4") This happens regardless of which plc I attempt to rename - it's like the 'myplc31' buffer doesn't recognize the 'close' and when the pre-processer sees the next 'open plc' it fails. If I re-define a different buffer, say, plc 7 to 'myplc7', then this error will be thrown on "open plc 8" since it follows next in the Solution Explore menu tree for the PLC Programs list. This may be a bug or I'm not using alphabetical names correctly to define a PLC buffer. Can anyone lend some insight?

I have a linear motor with an analog LVDT sensor that provides an absolute (bi-polar, +/- 10 volt) value of the motor position. I am setting this up so that on power-on, we read the position via an ACC28E (16 bit ADC). The issue is that the returned value does not compensate for the 32768 count offset that the ACC28 provides on a raw read of bi-polar data. (the ADC conversion is: counts out = (2^16 counts/20 volts)*volts_in + 32768 cts). So I have set the motor[x].homeoffset to account for this bias (effectively 10 volts * LVDT sensitivity). Unfortunately, this does not affect the motor[x].pos value or the motor[x].actpos values, only the reported position (e.g. #xp). In my case, the LVDT_sensitivity is 70 um/volt. So I placed motor[x].homeoffset = 700 and reset. Based on the relative position of the LVDT to the motor and with no power to the motor, this results in a motor[x].pos = 258, motor[x].actpos = 258, #xp reports -442. -442 corresponds to the true position of the motor while pos and actpos do not. Maybe I'm missing something, but the servo loop following error is based on the difference between the desired position and the actual position, both of which do not represent the true position of the motor. I would like to avoid dealing with this as an offset in either the motor[x].CompPos or motor[x].MasterPos registers. My aversion is for in the future when someone else tries to understand why we have a 'magic' number in one of the these registers. What is the best way to incorporate the effects of the 10 volt offset in my motor position? I've thought about cascading ECT entries to make the offset, but I'm not sure if that would be a preferred method or if there is some other superior solution. Set up: motor[x].PowerOnMode = 4 motor[x].pAbsPos = ACC28E[1].ADCuDAta[0].a motor[x].absPosFormat = $1010 // read bits 16-31 of 32 bit register as unsigned binary, I also tried reading a signed binary, but I saw no difference as I believe this setting is only determining if the MSb is a sign bit or not and my motor motion never exceeded what was required to flip the MSb. Thanks for any suggestions.

Eric, Thanks for the reply. I had not considered using an unused motor register for the comp table output. Good idea. My application is based on a lathe, where I have added a linear motor as a secondary X axis (i.e. u axis). I need to generate a trajectory for the U axis that is the superposition of two motions that depend on the Z axis position and the spindle position (theta), u = u1 + u2 where u1 = f(z) and u2 = g(z)*h(theta). I have implemented two 1-D compensation tables to generate the f(z) and g(z) functionality. I now need to get the product of g(z) and h(theta). I plan on implementing the h(theta) functionality, generating the product (g*h), and finally the summation of u1 to u2 as a c function at the servo update rate. I'm really just trying to take advantage of the existing functionality that already exists within the PPMAC to avoid writing my own look up table functions. Hope this sheds a little light on more of the big picture I am attempting. Thanks, Rick

I have a compensation table that I would like to write the output to a memory location instead of the tradition Motor[x].CompPos or Motor[x].CompDesPos registers. For my comp table setup I attempted: ... CompTable[1].Target[0] = Sys.Fdata[123].a ... which threw an 'error #70' Struct Write Data Error. Before attempting this, I had this same code working with the exception that the target address was assigned as: ... CompTable[1].Target[0] = Motor[3].CompDesPos.a ... Can anyone enlighten me on the right way to assign the comp table output to a memory location? Thanks, Rick

I am attempting to create a 'one-shot' Capture/Compare ISR. I have written the CaptCompISR(), and set UserAlgo.CaptCompIntr = 0 as part of my global definitions file. My expectation is that upon download, the ISR should not be called, even if the triggering conditions are met, since the UserAlgo.CaptCompIntr is set to 0. However, this is not what I am experiencing. As soon as I download the project to the PPMAC, I am seeing the effects of the ISR code. Specifically, the counter (sentinel, see code) value at Sys.Idata[65536] immediate starts counting up. I have placed the UserAlgo.CaptCompIntr in a watch window to verify that it is still set to 0. Background: I am setting up a system that has an externally controlled motor driving an incremental quadrature encoder that I have wired into channel 0 of the the only ACC-24E3 card in my rack. I want to capture the encoder count at the positive index. I want to capture the encoder count on just the first of 100's of index pulses that will occur. For now, I am just trying to get the ISR to run once, then disable itself. I have written a PLC to enable the ISR, but I don't even get to the point of running the PLC before the ISR starts running. I have done 2 things that I think should disable the ISR or the interrupt that acts as the source for the ISR call. 1) I clear the Gate3[].IntCtrl register (after making this register writable). Specifically, I want the clear the LSB of the interrupt enable byte of this register. This should, I think, disable the Channel 0 PosCapt interrupt. 2) I also set the UserAlgo.CaptCompIntr to zero, which should prevent the ISR from being called, even if the interrupt occurs. Finally, if I run the motor, I do get the *currentSpindlePos to change once every index pulse. Any ideas on what I'm doing wrong? Or how best to go about debugging this? My ISR code: void CaptCompISR(void) { /* declare pointers/variables */ volatile GateArray3 *Gate3IC; // Gate pointer declared int *currentSpindlePos; // pointer for position log of spindle encoder at trigger int *sentinal; // declare pointer to an integer /* initialize pointers */ Gate3IC = GetGate3MemPtr(0); // initialize pointer to Gate3[0] currentSpindlePos = (int *)pushm + 65535; // Sys.Idata[65535] (initialize pointer) sentinal = (int *)pushm + 65536; // Sys.Idata[65536] (initialize pointer) /* functional code */ *currentSpindlePos = Gate3IC->Chan[0].HomeCapt; // log the position of the encoder (*sentinal)++; // increment value at pointer Gate3IC->WpKey = 0xAAAAAAAA; // unlock write-protection Gate3IC->IntCtrl = 0; // disable further interrupts, SRM Pg 654, UM Pg 798 Gate3IC->WpKey = 0x0; // write-protect pshm->UserAlgo.CaptCompIntr = 0; // disable future calls to this ISR (enable in a plc that triggers at M50) } My Global Definitions code: Sys.Idata[65535] = 0 // initialize Sys.Idata[65536] = 0 // initialize Sys.Idata[65537] = 10 // initialize Sys.Idata[65538] = 20 // initialize EncTable[1].type=1 EncTable[1].pEnc = Gate3[0].Chan[0].ServoCapt.a EncTable[1].pEnc1=Sys.pushm EncTable[1].index1=0 EncTable[1].index2=0 EncTable[1].index3=0 EncTable[1].index4=0 EncTable[1].ScaleFactor = 1.0/256.0 EncTable[1].MaxDelta = 0 EncTable[1].SinBias = 0 EncTable[1].CosBias = 0 Gate3[0].Chan[0].CaptCtrl = 1 // 15 for index high and user flag // 1 for capture on index high only Gate3[0].Chan[0].EncCtrl = 3 // x4 quadrature decode CW (use 7 for x4 with CCW) Sys.WpKey = $AAAAAAAA Gate3[0].IntCtrl = $10100 // enable interrupt and set source on Chan[0].PosCapt Sys.WpKey = $0 UserAlgo.CaptCompIntr = 0; // disable capt/comp ISR My one-shot PLC that I would run to enable the ISR, but I'm not getting that far... open plc 4 Sys.Idata[65535] = Sys.Idata[65537] + 1 // initialize spindle capture Sys.Idata[65536] = Sys.Idata[65538] + 1 UserAlgo.CaptCompIntr = 1 // enable capture/compare ISR disable plc 4 close

I am trying to set up the Capture/Compare ISR routine as shown in the User's Manaul page 798, but I receive Error #75 when trying to enable the interrupt. (3 different ways now) This error occurs during the download process of my global definitions.pmh file. (maybe not the best place to test this out, ...) where I have included the line: UserAlgo.CaptCompIntr = 1 (The build succeeds, but errors on the download pointing to the UserAlgo line above. However, I have also attempted to: 1) eliminate the UserAlgo.CaptCompIntr setting from the global definitions.pmh file instead, writing directly in the terminal window, with: UserAlgo.CaptCompIntr = 1 again, receiving an error #75 as the response in the terminal window and 2) Adding UserAlgo.CaptCompIntr = 1 in the pp_startup.txt file as was suggested in the SRM entry for UserAlgo.CaptCompIntr. This also resulted in an error #75 during download. I'm running firmware version 2.3.2.5. Any ideas what I'm doing to cause this error? Do I have a configuration problem somewhere else that by attempting to enable the ISR we are being notified in a round-about fashion? The source code for the ISR has been added to the user.c module and the compiler seems perfectly happy with it.

I am interested if anyone has compiled Fortran for the PowerPC (specifically the 460EX). Are there executables and libraries available for doing this from DT? I have a developer that has Fortran source that I'd like to run in user space.

I am curious as to what the recommended upgrade path is to go from my current version of the IDE: 3.0.0.2, to the latest version 3.1.1. (I am setting up a second PPMAC for another developer, and I want to make sure that both PPMACs and IDEs are synchronized for this development effort.) I consider that doing a full upgrade is not advised and that doing the intermediate upgrades is required based on my read of: http://forums.deltatau.com/showthread.php?tid=2568&pid=10713#pid10713 However, there is no patch upgrade from 3.0.0.2 to 3.0.1.0 that I can find. 1) Does a patch upgrade exist from 3.0.0.2 to 3.0.1.0? 2) Is installing every intermediate IDE version actually required to do the migration from 3.0.0.2 to 3.1.1?

Update: I assume the Project was somehow corrupted - so I started a new Project and now can see the CPLC listed on the task manager. I also wonder about my usage of UserAlgo.BgCplcStatus[0] at the terminal window. I can't find any documentation on this element even though it shows up on the auto-completion list for the terminal window. The tool tip indicates that this should display the background C PLC execution status. This doesn't seem to work as it now returns 0 regardless of the execution state of my C PLC. Issuing UserAlgo.BgCplc[0], for example, does correspond to the state of the C PLC. Does anyone know if UserAlgo.BgCplcStatus is a deprecated feature? Thanks.

Update on this issue - I have 'resolved' the issue by scrapping the project and starting a new one. I assume something in the Project was corrupted somehow.