DLS_James

Hello, Are there plans to ship PowerPMACs with a newer version of Python installed, or are there instructions for how we can upgrade existing units? The installed version is 2.7.9. It would be great to have at least version 3.7+ Thank you, James

Thanks @Alex Anikstein that's very helpful

Hello, Is there a straightforward way of disabling telnet on PowerPMAC products? We are looking to increase the cybersecurity of our units. I understand that the IDE and its tools all use ssh, so we wouldn't lose any functionality if telnet wasn't available? Thanks, James

Thank you Leandro and Gregs

Hi Leandro, Yes that also didn't work

We have an older model of PowerPMAC (Linux powerpmac 2.6.30.3) running firmware 1.6.1.181 We are able to interact with it using a modern version of PowerPMAC IDE (4.6.2.15), to read and change variables for example, but we are unable to use the Gather tool. The tool window will open and the first step of running the gather appears to work. However, when we attempt the next step of uploading the gathered data, the program just hangs indefinitely. On older versions of the IDE (eg 2.0.0.25) the Gather tool window opens, but then immediately closes. Is this problem known about and is there a solution? Thanks for any help, James

Hello, I've been working at the motion program approach for some time now but had some success today.... I found that I could get reliable triggering from a PLC (but obviously without any motions) with the following code: #define DET_TRIGGER_OUTPUT Acc65E[0].DataReg[3].3 #define trig_count p1401 #define TimeDelay 0.005 open plc 14 local delayTimer; while(trig_count < 5000) { delayTimer = Sys.Time + TimeDelay; DET_TRIGGER_OUTPUT = 1; while (Sys.Time < delayTimer) { } delayTimer = Sys.Time + TimeDelay; DET_TRIGGER_OUTPUT = 0; while (Sys.Time < delayTimer) { } trig_count++; } CLOSE; So this morning I stripped the motion program right down and removed all motion elements so it resembled the PLC code as closely as possible (with the main loop identical to above). Curiously this setup could never achieve more than 4096 while loop cycles before it locked up. Less than 4096 it would run to completion, but any more and it would hang. 4096 is too much of a magic number to not be linked to some limitation in the system....I would be interested to know if anyone can shed any light on this limitation? However, even with this stripped down version running less than 4096 loops it still couldn't reliably trigger. I tried various arrangements of the code and subroutines with no luck. In the end the successful collections came by modifying the motion program so that it didn't send trigger requests to the hardware directly but would just set a p-variable. Then I had a PLC running alongside the motion program and monitoring this p-variable. The PLC would be the one to actually send the request to the GPIO hardware. It is not a very elegant solution but seems very reliable. Every collection has been successful. I have run 4 successful collections with a 20ms mark/space length (2 of 4000 steps, 2 of 5000 steps), and 2 successful 5000 step scans at 5ms mark/space length. It seems that motion programs are unreliable at talking to hardware directly, I'm guessing it has something to do with the way they buffer upcoming moves; it must mess up the timing? Thanks, James

Thank you both for your replies and the information. AAnikstein - what are the two different EtherCAT implementations that you support?

Hello, I'm interested in understanding the procedure and workload involved in setting up a PowerPMAC as an EtherCAT master motion controller controlling an EtherCAT slave motor which is supported by Delta Tau. How much of the interface is automated? Looking at forum posts (such as this one: http://forums.deltatau.com/showthread.php?tid=2676), I see that things like I/O require a mapping between Delta Tau variables and the EtherCAT hardware registers. But for a supported motor is it as simple as getting the PowerPMAC to search the EtherCAT chain for a new device and then selecting this device and assigning it an axis number? For example, if I have software which knows how to talk to Delta Tau i-variables (ie to set speed and acceleration) would these i-variables also need explicit mapping to EtherCAT registers or would this be handled by automatically by the controller when the connected slave device is selected? Thanks for any info, James

Hello, We are using a motion program to increment motor positions and then send out a trigger pulse from the GPIO at each new position (a step scan, triggering a detector at each step) Generally this works well, but we have noticed that we occasionally have missing trigger pulses. eg If I run a 5000 point scan I may only see 4996 triggers from the GPIO. When I monitor the output I see that occasionally a trigger pulse is remaining high for over 2.5 times longer than usual, enough time to cause the next rising edge to be ineffectual. ie - the pulses we are missing are being swallowed up by the previous trigger remaining high for too long. This appears to happen at random - there is no apparent periodicity to these long pulses and I can get a different number of them per scan (although typically in the order of about 4-10 per 5000 points) Below is the way we have structured our motion program: #define TRIGGER_OUTPUT Acc65E[0].DataReg[3].3 open prog 11 WHILE(COUNTER < NUM_STEPS) { CALL SENDTRIGGER; COUNTER = COUNTER + 1; DWELL 10; } RETURN; CLOSE OPEN SUBPROG SENDTRIGGER X(X_MOVE); DWELL0; TRIGGER_OUTPUT == 1; DWELL(DWELL_TIME/2); TRIGGER_OUTPUT == 0; DWELL(DWELL_TIME/2); RETURN; CLOSE What could be causing the random long pulses? Is there a better, more reliable way to trigger GPIO outputs for this type of task? Thanks for any guidance, James

Hello, I made a backup of a PowerPMAC project using version 1.7.0.53 of the IDE. Later I upgraded the IDE to a later version downloaded from the Delta Tau website. When I tried to perform a restore of my backup using this new IDE, it informed me that it couldn't do it as the CPU it detected didn't match the CPU of the backup file. The difference was that the IDE detected a revision b of the CPU in the hardware but the backup didn't record this revision. Luckily I still had my old 1.7.0.53 installer and so downgraded to perform the restore. It feels to me that the CPU type checking is too stringent on the newer IDE - can it just do a check against the main version number and not the revision? Or can it give an option to restore anyway despite the apparent difference? Thanks, James

Thanks for all the replies and help! You've given me plenty to investigate. I shall give your suggestions a whirl.....

Hello, I would like to be able to set the feedrate of a coordinate system from a PLC. There doesn't seem to be a Coord[1].Feedrate command so I tried, cmd "&1%0" instead, but this gives the following error: error #31: invalid format in string: cmd "&1%0" What is the correct/best way to be able to do this? Thanks, James

Cool! Thanks, that's useful. James

Hello, Tony Jacobs has given me an easier answer. I can address the card directly: eg acc65e[0].datareg[y] where, y = 0 for pins 1-8, 1 for pins 9-16, 2 for pins 16-24 (input) y = 3 for pins 1-8, 4 for pins 9-16, 5 for pins 16-24 (output)