michaelthompson

Thanks Curt. We will give those a try. We had considered the cx command, but couldn't tell from the documentation whether it would be any different than the cpx command regarding its execution synchonization. It was getting late in our testing last night and I decided to reach out for help today instead of endlessly searching. I appreciate the fast response. It's still worth considering either a ?: and/or if() function evaluation in your future plans. Also, logical operations don't seem to be supported in the command-line parser. They would be handy on occasion.

Incidentally, there are other options that are kind of ugly: // assume metricUnits is a 1 or 0 value // when metricUnits is a 1, conversionFactor = 1*millimeters+(1-1)*inches = millimeters // when metricUnits is a 0, conversionFactor = 0*millimeters+(1-0)*inches = inches conversionFactor=metricUnits*millimeters+(1-metricUnits)*inches One could also use an array where the value of metricUnits is the index into the array. Neither approach is as readable as a conditional operator or conditional function. Even the above could be more friendly if the following were allowed: conversionFactor=metricUnits*millimeters+(!metricUnits)*inches

We have a need to perform conditional assignments within scripts that are piped to gpascii, but we can't find any conditional operator or function which works within the on-line command language. For example, we would like to do: conversionFactor=if(metricUnits,millimetersPerBaseUnit,inchesPerBaseUnit); or equally effective using a conditional operator: conversionFactor=metricUnits ? millimetersPerBaseUnit : inchesPerBaseUnit; Neither of these are supported (either in the command-line or script language). We thought we had a solution by using the cpx command: cpx if(metricUnits) conversionFactor=millimetersPerBaseUnit else conversionFactor=inchesPerBaseUnit but that doesn't work because the cpx command is asynchronous and we have no way from the command line to wait for it to complete before proceeding with other assignments which use the conversionFactor we wish to assign. We are looking for other ideas, suggestions, or consideration given to adding either a conditional operator (?:) or if() function to the expression evaluation.

What about these? http://www.redrives.net/product/10136/10136-3M-Connector-Mini-D-Ribbon-MDR-Solder-Plug.html http://www.newark.com/3m/10136-3000pe/mini-d-ribbon-conn-plug-36pos-solder/dp/69K7226 http://www.digikey.com/product-detail/en/10136-3000PE/3M1770-ND/773865

Not sure if this is the correct style of connectors: http://www.digikey.com/product-highlights/us/en/norcomp-micro-d-connectors/1059

This list might help for those using the DB-15 connectors (analog mezzanine card). Note that some connectors in my list are for other devices. Norcomp via Digikey might be able to provide the connectors for the digital (PWM) mezzanine card. I haven't had a need to look them up yet. Note that we have found that the 45 deg exit hoods work well to take the cables toward the back of the unit. Norcomp Connector, DB-9, Male, Gold Flash, Solder Cup 172-009-102R001 Norcomp Connector, DB-9, Female, Gold Flash, Solder Cup 172-009-202R001 Norcomp Connector, DB-15, Male, Gold Flash, Solder Cup 172-015-102R001 Norcomp Connector, DB-15, Female, Gold Flash, Solder Cup 172-015-202R001 Norcomp Connector, DB-15, Male, High Density, Gold Flash, Solder Cup 180-M15-103L001 Norcomp Connector, DB-15, Female, High Density, Gold Flash, Solder Cup 180-M15-203L001 Norcomp Connector, DB-26, Male, High Density, Gold Flash, Solder Cup 180-M26-103L001 Norcomp Connector, DB-26, Female, High Density, Gold Flash, Solder Cup 180-M26-203L001 Norcomp DB9, Back Shell, Zinc, Nickel Plate, 180 deg, 4-40 Thumb Screws 970-009-030R121 Norcomp DB15, Back Shell, Zinc, Nickel Plate, 180 deg, 4-40 Thumb Screws 970-015-030R121 Norcomp DB15, Back Shell, Zinc, Nickel Plate, 45 deg, 4-40 Thumb Screws 971-015-030R121 Norcomp DSub Coupling Nut, 4-40, Female, Nickel Plate 160-000-006R032

We are attempting to consolidate all of our source code (various platforms) such that it can be completely managed under Visual Studio 2010 and version controlled with Microsoft Team Foundation Server (TFS). For older PMAC software (PMAC2 and Turbo PMAC), we are creating Visual Studio 2010 solutions/projects as wrappers. For the Power PMAC, we can do the same, but then we will be forced to maintain two project files (the Visual Studio 2010 project file we create plus the Power PMAC IDE project file). It would be preferred if we could simply open the existing Power PMAC solution and project files in Visual Studio 2010. Unfortunately, neither the _sln nor the .ppproj files are recognized (other than as text files) under Visual Studio 2010 and there doesn't seem to be a way for the Power PMAC IDE to connect to TFS. Is there any work going on at Delta Tau that might address this concern?

KEJR, It seems that all of our problems so far have been with exim and permissions. However, even with the permission changes, we still haven't been able to get it configured properly to send the mail through our relay. I verified that our relay is set up to allow the e-mail from the Power PMAC node by the following telnet session (which produced a test e-mail): telnet mailrelay.mydomain.com 25 Connected to mailrelay.mydomain.com. Escape character is '^]'. 220 mailrelay.mydomain.com ESMTP Sendmail 99.99.99/99.99.99; Mon, 28 Jan 2013 14:38:34 -0500 (EST) helo user 250 mailrelay.mydomain.com Hello myhost.mydomain.com [147.185.28.219], pleased to meet you MAIL FROM: 250 2.1.0 ... Sender ok RCPT TO: 250 2.1.5 ... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Test message . 250 2.0.0 r0SJd8q03075 Message accepted for delivery This technique is described here (although I'm sure there are better examples out there): http://www.febooti.com/products/automation-workshop/tutorials/test-smtp-connection-send-test-email.html So, as a last resort, we could talk directly to the mail relay as I do above, but that would cause us to lose the benefits of exim (queuing, error handling, standardization, etc.) I believe that our systems are all Lenny. I haven't checked versions or updated the exim package. I'm pretty sure the only thing we are presently doing above and beyond the Delta Tau install is setup for our network access, samba, and an ntp daemon. Thanks for all of the help you've provided. I'm sure we'll eventually crack it, but it may take some work since nobody on this end is a Linux e-mail expert either.

Of course, but it is the standard operating system, standard file system, standard communications protocols, and standard programming language that makes the Power PMAC more powerful and desirable to Delta Tau's customers than earlier PMACs. Locking down the operating system would be a mistake, regardless of whether it is Linux or Windows. The question for this thread is why the PMAC IDE doesn't have its own account and set up the prompt the way it needs. Or conversely, why don't the users who want to customize the prompt set up special user accounts to do so?

FEIR, From a CPLC, you can use the C system() function as opposed to the Command call to system provided by Charles.

KEJR, After running the reconfiguration and attempting to send mail, we get permission denied messages: root@xxx.xxx.xxx.xxx:/opt/ppmac# echo "this is a test" | mail -s "subject line" recipient@mydomain.com 2013-01-27 20:40:13 1Tzdhl-0000xF-3Q Cannot open main log file "/var/log/exim4/mainlog": Permission denied: euid=101 egid=103 2013-01-27 20:40:13 1Tzdhl-0000xF-3Q Failed to create spool file /var/spool/exim4/input//1Tzdhl-0000xF-3Q-D: Permission denied 2013-01-27 20:40:13 1Tzdhl-0000xF-3Q Cannot open main log file "/var/log/exim4/mainlog": Permission denied: euid=101 egid=103 exim: could not open panic log - aborting: see message(s) above Can't send mail: sendmail process failed with error code 1 We can resolve this by changing ownership of the directories and modifying the Debian-exim user to be part of the root group as follows: root@xxx.xxx.xxx.xxx:/opt/ppmac# usermod -a -G root Debian-exim root@xxx.xxx.xxx.xxx:/opt/ppmac# chown -R Debian-exim:root /var/log/exim4 root@xxx.xxx.xxx.xxx:/opt/ppmac# chown -R Debian-exim:root /var/spool/exim4 However, making Debian-exim part of the root group might be solving the permission denied problem with a hammer. Would you know the preferred solution to this sort of problem? There are a lot of posts online about exim4 problems with permissions, but it isn't clear what the recommended solution is. Also, I'm wondering why you didn't run into this problem. Mike

KEJR Great! Thanks. We will give it a try and post our experience. Mike

KEJR, We considered that approach (and your other posts/discussions were helpful), but we decided to stay within the PLC model for now (which I believe is single process, multiple thread). That said, we have a couple of external (built and run outside of the context of the IDE) C applications for communications over sockets, logging, etc. What's nice is that Delta Tau gave us the flexibility to develop/operate in either way, or any combination. Agreed 100%, not to mention all of the other benefits C++ provides with classes, encapsulation, inheritance, polymorphism, etc. I understand Delta Tau needing to focus on the broader audience, but when they get C++ capability within the IDE, it will take the product to another level. The watchdog trips after 1000 ms (configurable) of not receiving a trigger pulse. When it trips, it puts all of the drives in Safe-Torque-Off mode (MOSFETs disabled). We are using Copley Xenus Plus drives and they support Safe-Torque-Off as separate from the enable line. However, the drives are not being used to commutate the motors (the PMAC is) so the drive can't handle the deceleration itself. In order to handle E-STOP, we let our E-STOP switch break the trigger signal to the watchdog timer. This means that the the watchdog timer will keep the drives out of the Safe-Torque-Off state for 1000 ms, long enough for the PMAC to execute a powered abort deceleration (which we can do in about 500-600 ms from our maximum velocity and inertia states). After the 1000 ms, the drive goes into Safe-Torque-Off state because of the watchdog relay. Redundantly, the PMAC will individually disable each drive (enable line) after any aborted motion completes (actual velocity less than some small value) and/or after some timeout period (i.e. 1000 ms) as a catch-all. What we gain with this approach is: 1. Elimination of all relays and braking resistors 2. Watchdog is only relay we presently require and it only switches 24V, low current Safe-Torque-Off line 3. Controlled and rapid E-STOP, much faster decelerations than resistive braking approaches 4. Safety logic implemented in software and managed with version control 5. Failsafe and redundant The only thing we lose over our older relay logic approach is static braking. Our older relay logic used resistive braking in the E-STOP state. The motor was disconnected from the drive and connected to a resistive load. This resistive load makes the air bearing stage harder to move in an E-STOP state (like moving through molasses). Without resistive braking in the E-STOP state, the air bearing floats freely. Depending on one's expectations, the elimination of static resistive braking can be considered a drawback or a benefit. In either case, it doesn't impact safety. Much appreciated! Mike

KEJR, Now that I think about it, if you are doing all of your development in external Linux applications, then perhaps that is why you have never watchdogged the Power PMAC. I think the watchdog occurs because the necessary "kick" doesn't occur within Delta Tau's PLC scheduling system (due to PLC lockup, exception, etc.) You can trap external applications all you like and never watchdog the PMAC. Mike

KEJR, Thanks for the info. Based on your other postings and the amount of experience you have with the Power PMAC, I'm a little surprised that you have yet to watchdog it! We have done so with bad pointers and locked PLCs on a few occasions (both accidentally and intentionally). Our experience is that Linux applications continue to run when you watchdog the PMAC. This is unrelated to the thread, but it is worth noting that we don't get any benefit from the built-in watchdog relay. The problem is that we don't get to specify the conditions under which the Power PMAC watchdog trips. To address safety issues, we need the watchdog to trip if a particular safety PLC fails to run its periodic scan (regardless of why). This includes the case where someone disables the PLC (or it disables itself deliberately or accidentally). The normal PMAC watchdog will not trip if we disable our safety PLC because our safety PLC is not required to "kick" it to keep it happy. As far as I know, Delta Tau's watchdog system does not allow us to operate it in that fashion (it would be nice if it did). Nor does it allow us to reset it after a watchdog event occurs. Once we watchdog the Power PMAC, we are forced to reboot. Consequently, we implement our own external watchdog relay with an ABB device. It is the only relay in our system (5-axis custom coordinate measuring machine). Our safety PLC "kicks" the ABB timer relay every 50-100 ms to keep it happy. If we fail to do so, it trips, triggering abort of all moves followed by a safe-torque-off (and disabled) state on all of our amplifiers. It works great, but we wouldn't need the ABB relay if the PMAC watchdog system supported a "user-kick" requirement and reset capability. Anyway, regarding the e-mail support, I think we need to install a mail package first. Our earlier investigation led us to believe that no mail package is installed out of the box (or at least not set up). It's low priority so we haven't done much other investigation since my last posting. I was sort of hoping that you might have already cracked it since, from past postings, you seem to be working with the Power PMAC in a way that most closely resembles our own use. The one difference is that we are using the PLC system plus external Linux applications and it sounded like you were doing all of your development as external applications. Thanks again for your reply. Hopefully, Delta Tau's Linux experts will give us some guidance and save us from investigating further on our own.

Has anyone set up the Power PMAC to send e-mail? We are looking to package our debug dumps during certain events and e-mail them directly to our support staff. We have used sendmail in other environments to do this but have not yet performed the required setup under Linux. We envision a few different scenarios such as when a watchdog or similar serious/unusual event occurs. For the watchdog case, there would be a C application running and monitoring the watchdog status. When detected, we would use gpascii to dump P and M variable tables as well as our "black box" gather buffer. The dump would then be sent as an attachment(s) to an e-mail.

Thanks Curt. I appreciate the support. We made the change to use Motor[x].Desired.Pos instead of Motor[x].DesPos. Motor[x].Desired.Pos works perfectly and mimics the cascaded behavior of our Turbo PMAC solution (which writes to D:$000088). Motor[x].MasterPos is no longer needed by our Power PMAC algorithm now that we know how to set desired position. We only investigated Motor[x].MasterPos because of our failed attempts with Motor[x].DesPos.

Curt, Thanks for the reply. I agree with you on the matter of resolution. Nevertheless, we will try Motor[x].Desired.Pos instead of Motor[x].DesPos in our next round of testing. Can you offer any further explanation about the difference between Motor[x].Desired.Pos and Motor[x].DesPos?

For clarification, our Turbo PMAC algorithm updates Mxx61 (D:$000088) which is listed as equivalent to Motor[x].DesPos.

Curt, Thanks for the reply and for the reassurance. I believe that you are correct (particularly if the residual argument is valid), but I think it is still worth going through the calculation. Typical Axis Resolution: 1.2 nm/cnt Typical Force-Mode Maximum Velocity: 100 mm/s Assuming only a 52-bit mantissa, we will lose one bit of resolution for every 2^51 accumulated counts. Further assuming a worst-case MasterPos accumulation of: 100 mm/s 8.33e7 cnt --------------- = ------------ 1.2 e-6 mm/cnt s It will then take 2^51/8.33e7 seconds (0.85 years) of unidirectional accumulation at the maximum velocity to lose one bit of resolution. So, you are correct that we are unlikely to see a loss of resolution under these conditions. Even so, I would feel better if I could zero the MasterPos after its job is done. It should be a trivial exercise in any of the user servo functions if I only knew which register I should poke into. For example, if the register of interest was Motor[x].CmdPos, the code to clear out MasterPos in user_pid() would look like: Motor[x].CmdPos-=Motor[x].MasterPos; Motor[x].MasterPos=0; Of course, if I could poke into Motor[x].CmdPos (and not have my value get overwritten), then I wouldn't need to use Motor[x].MasterPos as an accumulator. Further, I would have a solution which looks mostly identical to our Turbo PMAC solution.

Sina, I wouldn't expect interrupts to be a concern since our code is running in a user_pid block. It seems to me that no other code (firmware or PLC) should have the ability to change the commanded and/or the master position of my motor during the time that the user_pid code is running. Note that we are trying to do exactly what we did on the Turbo PMAC (which is to feed the commanded position as if we are a trajectory generator). The problem is that Motor[x].DesPos gets overwritten (possibly by the command prefiltering?) and we don't know what register feeds the command prefiltering. To understand our application, just think about a CMM (coordinate measuring machine) which has a probe that approaches a part by riding on a motorized axis until it is deflected to some target force. Then, it continues to maintain constant force until some scanning motion (using another axis) is complete. Once complete, force-mode servoing is disabled and normal motions are used to retract the probe away from the part. You can think of our force-mode following algorithm as a dynamically controlled trajectory generator (where the trajectory is controlled by the force error signal). The only difference is that, when the force-mode servoing is turned off, we want to revert to position control at the motor's present actual position (not the actual position when force-mode servoing was enabled). That's why the normal mode MasterPos doesn't work (unless we allow it to accumulate). My concern about the accumulation in MasterPos is that it is not an integer register. It doesn't just roll over. It is a double precision floating point value. Consequently, resolution is ultimately traded off for range if the magnitude gets large. At some point, MasterPos could accumulate to the point where resolution is lost and the force-mode servo following stops working. We either need a way to zero MasterPos (with no motion) while the motor position loop is closed or we need a way to feed the commanded position like we used to do on the Turbo PMAC.

We are converting a custom force-mode following function from our Turbo PMAC implementation to our Power PMAC implementation. On the Turbo PMAC, we used a custom user-servo function running under an unused motor (#6). The algorithm reads a force from a designated sensor, applies PID gains to the force error, and then modifies the commanded position of a desginated motor (#1 through #5). As such, it is a fairly classic example of a cascaded loop. On the Power PMAC, we are using a user PID task for motor #6 and are attempting to modify Motor[x].DesPos with no success. Motor[x].DesPos is apparently written by Delta Tau firmware on every servo cycle (even when no motion commands are pending). Searching for a solution, we tested Motor[x].MasterPos in normal mode. We found that Motor[x].MasterPos works quite well for us with only one problem. We are concerned about accumulated distance in the Motor[x].MasterPos register and need to reset it to zero at the start and/or end of our force mode servoing. When we attempt to do this, the motor jumps back to its original position. It is clear that we need to simultaneously change Motor[x].MasterPos and Motor[x].DesPos, but Motor[x].DesPos is written by Power PMAC firmware on every servo cycle. So, we are back to square one. Q. What motor register can we write to in order to effect a step change in commanded position? Q. Is there a way to zero the Motor[x].MasterPos register of an active motor without causing motion? Please provide examples.

Sina, Although the index P-variable example I tried worked, the named P-variable example does not appear to work for us. Doing something like: Gather.Addr[1]=Sys.P[myPVariable].a generates an error because it converts Sys.P[myPVariable].a to Sys.P[P8123].a instead of Sys.P[8123].a This gets back to needing the ability to get the index number associated with a given named variable.

Sina, Thanks. That also appears to work for our M-variable mapping approach: M1001->Sys.P[8105] Appreciate the fast response. Still interested in the multiple gather buffers if you ever see the opportunity to do that. Thanks again, Mike

We are trying to implement greater flexibility in the specification of our data gathering function. Specifically, we would like to pass to the Power PMAC a list of strings at runtime which describe what we would like to gather. For example, we might want to gather any of the exposed PMAC structure elements such as Motor[1].ActPos, but we might also want to gather global P-variables that have been defined and which get modified by our servo and PLC loops. When we use the PMAC Plot program, we can specify gathering of our global P-variables within the Detailed / User Global list. However, we have not found any way to determine the address of a P-variable if we wish to build the gather table from a script, gpascii session, or GetPMACResponse call. Example: Gather.Addr[1]=Motor[1].ActPos.a // works Gather.Addr[2]=myPVariable.a // fails Gather.Addr[3]=P4123.a // fails Gather.Addr[4]=P[4123].a // fails How does the PMAC Plot program manage to determine the address of the P-variables, and is there a way for us to do the same? We are actually doing our primary data gathering ourselves and had planned on using M-variable indirection, but we run into the same problem there. For example, assume my gathering will always acquire M1001 through M1008. If I want to map M1001 to P4123, there does not appear to be a way to do it. M1001->P4123 // fails M1001->P4123.a // fails In order for us to implement a flexible data gathering function, we need to be able to determine both the address and type of any named variable (whether it exists in the Delta Tau structures or not). It would seem that the following would be worth doing (and should be possible): 1. Allow M-variable mapping to P variables (or any other variables for that matter). 2. Allow syntax for .a on all variables (including P variables). This could also be handled with something like AddressOf(myPVariable), AddressOf(M1234), etc. 3. Allow syntax for .t on all variables (including P variables). This could also be handled with something like TypeOf(myPVariable), TypeOf(M1234), etc. 4. Allow syntax for .i on all indexed variable tables. This could also be handled with something like IndexOf(myPVariable). Note that, rather than write our own gather code, we would prefer to use PMAC's gather capability for all of our data acquisition needs, but it is currently limited to a single gather buffer. We therefore only use it for what we call "Black Box" or "Flight Recorder" mode. In this mode, we capture the last minute or so of data continuously in circular fashion. If an E-STOP or other error event occurs, we stop the black box capture (after waiting for several seconds of post-event data) and can then upload and analyze the data. Note that our normal data acquisition would also be occurring simultaneously in the servo loop in a different buffer (and possibly with a different sampling frequency and data list), but it uses the M-variable mapping to specify what gets gathered (only because we can't set up multiple gathers). It would be really nice if we could have several simultaneous gathers running (so long as the rates are kept low enough that the servo/phase interrupts have time to execute). An example of the simultaneous gather buffers we might use are: 1. Normal position / sensor capture for application use 2. Black box recorder for triggered event capture 3. Low priority logging of environmental conditions, motor power, etc. 4. Diagnostic data gathering using PMAC Plot program The reason these make sense to capture as separate gathers is because they have different data of interest, different durations of interest, and different sampling frequencies. It should be possible to accomplish multiple gather buffers by making all of the gather setup functions arrays: // set up first gather operation Gather[0].Addr[0]=...... // set up second gather operation Gather[1].Addr[0]=.... etc.