Jump to content
OMRON Forums

michaelthompson

Members
  • Posts

    57
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

michaelthompson's Achievements

Contributor

Contributor (5/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. 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.
  2. 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
  3. 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.
  4. 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
  5. Not sure if this is the correct style of connectors: http://www.digikey.com/product-highlights/us/en/norcomp-micro-d-connectors/1059
  6. 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
  7. 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?
  8. 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.
  9. 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?
  10. FEIR, From a CPLC, you can use the C system() function as opposed to the Command call to system provided by Charles.
  11. 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
  12. KEJR Great! Thanks. We will give it a try and post our experience. Mike
  13. 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
  14. 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
  15. 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.
×
×
  • Create New...