Jump to content

tmoulder

External Moderators
 View Profile  See their activity

  • Posts

    196

  • Joined

  • Last visited

  • Days Won

    4

 Content Type 

Blog Entries posted by tmoulder

  1. tmoulder

    Motoman CanOpen Example

    By tmoulder,


    CanOpen
    Greetings all!
    Motoman is a Yaskawa-based robot company that offers CanOpen as one of their protocols. The documentation for their card is good for the wiring and installation of the CanOpen adapter card, but documentation about how the robot interacts with the card, and how CanOpen commands are processed is non-existent. Literally, it doesn't exist.
    I've begun a project requiring interfacing a V570 to a Motoman robot via CanOpen, and the attachments here cover my findings. There's an example program (based on the Wago one posted to my blog), and a user guide that explains how the interfacing works, and what I learned about the Motoman CanOpen inplementation.
    Hopefully, it will give the next guy some guidance I sorely missed out on.
    As an added bonus (?), the Motoman card is non-retentive, and a heartbeat has to be set every time the robot is powered up. So if you were longing for a bit about SDO, it's here.
    Hope it helps!
    TM
    Motoman CanOpen Module.vlp
    Motoman CanOpen.pdf
  2. tmoulder
    Notice: This is an example program, instead of an importable module. The way CanOpen is confgured in Unitronics makes an importable module for this impractical.
    The program is an example of communication with a Wago 750-307 IO node. The node I used to develop it has 16 digital inputs and 10 relay outputs. Refer to the documentation of the node to see how to set the Unit ID for the node, the program looks for node 1.
    I designed the NMT section of the program to mainly to handle automatic launch from Pre-Operational to Operational mode at power-up, and to recover if the node is disconnected. Error messages are checked against the error register to see if they are legit, and an alarm bit in the PLC is set if this is the case. Otherwise they are ignored. PDOs are not processed until the node is seen as operational in response to the Node Guard request.
    The 307 uses Node Guarding, and the scheme is designed around this. I noticed a change between Unitronics' processing of Node Guard signals (Toggle Bit no longer toggles, Received bit is triggered) in the latest OS, vs the previous one. It's actually an improvement, but I don't know if they will go back to the old method. It works with OS 3.3.3 on the 570.
    I hope you find it useful. If anybody can think of a good way to make it importable, please share!
    TM
    Wago 750_307 Module.vlp
  3. tmoulder

    CanOpen Basics

    By tmoulder,


    CanOpen
    As a supplement to the example program I posted earlier, I've put together this PDF guide. It explains how the program operates, and goes into some light detail about CanOpen itself, as implemented in Unitronics. Hopefully, it will help give the new CanOpen-er a boost in the right direction.
    Like everything in this blog, this is open. If you see a correction or think something needs covered that isn't, let me know and I'll add on to it.
    Hope it helps!
    TM
    CanOpen Primer.pdf
  4. tmoulder

    Thoughts on Linux

    By tmoulder,

    Like alot of people, I still use Windows XP for running my work-related programs. I know, lost in the 90's, but it works well for me.
    About a year ago, I had a PC crash that set me back severely. I didn't lose any data - for years now, I've kept all my project data in a single folder, and copy-pasted to my backup hard drive regularly. However, it took three days to reinstall all the software after I recovered the PC.
    That got me thinking - there's got to be an easier way to do this.
    As the first entry on this blog describes, I've dabbled with Linux for a while, and with some sound advice, I decided to make the leap. I wiped Windows from my PC and installed Linux Mint 11. Then I downloaded VMware Player, created a new Vitrual Machine, and installed XP on that.
    I was prepared for a raft of headaches arising from this - oh no, linux! oh no, vmware! - hardware issues, software issues, pain, hate, discontent! What I got was - nothing at all. No problems, no issues. The whole thing ran magnificently. Best of all, I can now back up my entire windows virtual machine to my backup drive.
    Why is this so grand, you ask? Because my work PC is now essentially indestuctable. I can drop my laptop in the swimming pool, buy a new one, load Mint and VMware, drag-drop my saved VM into my home directory, and get right back to work. Alternatively, I can upgrade to a new pc and get rolling equally fast.
    In the process, I've learned a few things, so if you decide to go this route, you may find these experiences helpful -
    1. You can't do this with a netbook, at least not an Acer. Not enough ram, and atom chips lack the needed horsepower. Get a laptop with a 64-bit architecture, that you can upgrade to at least 8 Gig of Ram, and a hard drive large enough to accomodate everything you'll need. On the ram side, get as much as you can - mine has 5 gig, and I'll be upping it to 8 gig after the holidays.
    2. The temptation is to use a minimalist distro, so you can allocate maximum resources to the VM (where you are doing all the work, after all). Resist this. I've played with Puppy, DSL, Bodhi, and Mint LXDE, and what you gain in performance for the VM is neglible, particularly in relation to the difficulty of using a minimal distro (unless you're into that kind of configuration headache).
    Choose something that provides all you need up front. Linux Mint is an excellent option - it's based on the widely used Ubuntu, but includes alot of extras that Ubuntu makes you find yourself. I'm using Pinguy OS, which is derived from Linux Mint, and offers even more eye candy - who wants an ugly desktop?
    3. As you can probably guess, I tried a lot of distros. Everybody makes a big whoop about live cd and live usb, but I found testing them that way to be a little pointless - you can't add software (need to test with VMware) and performance lags going that route, so you don't get a true flavor of what you'll have when installed. Apart from seeing if you like the screen, you'll pretty much have to install it to try it out.
    So the first time you go to set up linux, create a home partition on your hard drive. When you install most distros, you'll have the option to assign this partition as your home directory. You can install the new system into the rest of the drive, and usually not have to move your important personal files around.
    WARNING - that's not fool-proof, so make sure you back up your files first. If it works, it will save you alot of time and aggravation. But if something gums up, it'll kill you if you haven't backed up first.
    4. When creating your Windows VM, dedicate some thought to division of responsibility. Simply put, if it doesn't need to be in the VM, put it in the linux host instead. I have about 2 gig of PDF reference files that used to be under windows, that now rest comfortably in my linux home directory, outside my VM. Accessing them is a breeze, with or without windows open, and it keeps the VM smaller. When you do run a backup, you can just backup the contents of the home directory - drag, drop, done - and preserve everything you need, including your VM and external files.
    On the hardware side, 99% of everything I've tried has worked great. The most obscure thing I use is PCanOpen Magic Pro, with a USB adapter, and it worked right out of the box. I use an Iconcepts USB to serial adapter for most programming jobs, and it runs flawlessly.
    Oddly, the only thing I've had trouble with is a Unitronics 1040 PLC - can't do direct USB to the panel. Apparently, there is a known issue with the linux driver for the usb-serial chip Unitronics used in this device. It's a linux issue, not a Uni issue (just to make that clear). So I just use my usual serial port adapter instead - no problems there.
    Detailed instructions for how to do all of this are readily available on the web. Personally, I've found it a huge help (already recovered once [me and my distro hopping]).
    Best of Luck, and remember - backups are your friend. This mainly about making them more complete and portable.
    TM
  5. tmoulder

    Simple Alarm Module

    By tmoulder,

    Unitronics has provided us with a powerful and comprehensive alarm system built into the OS. It provides grouping, status conditions, and pre-made screens to interact with. It's a terrific piece of work, and I do not wish to detract from it one bit.
    That said, it's also complex and can be tricky to set up. The vast majority of my projects don't need anything that sophisticated. So after several years of working on my own technique, I finally came up with a module that matches just my needs, keeping it simple and sweet.
    The attached program is a simple alarm system. It uses the legacy Events FB, a string library to store text for alarms, and UTC date and time stamps. There are 12 entries on the screen, active alarms are highlighted in red, and go white when cleared, leaving a 12-point history behind. The Event Rise FB ensures that all alarms are captured, even if they occur simultaneously.
    This module in particular seems ripe for expansion. You could modify it to scroll and add more alarms to the history, and /or use Log to SD for long-term history. But as I said, those just aren't something I generally need.
    One limitation that comes to mind is that if more than 12 alarms occur at once, some will be knocked off the list and not visible. To which I say, if you have more than 12 alarms occurring simultaneously, you may have bigger problems than the length of the list
    Enjoy!
    TM
  6. tmoulder
    So after a lengthy wait, I finally got the go-ahead to execute my long awaited CanOpen rebuild project in November. I can't go into the details of the machine itself, but I wanted to share a few critical learnings from contending with it during the installation and commissioning.
    1. AC Tech Servo Drives - worked like champions, but I ran into an issue with the OEM limit switches. These were two-wire proxes, and leakage current wrought havoc on my sensitive new drives. This was addressed by installing relays on the switches, which provided a load to prevent false triggering. I also took it a step further and fully isolated the 24VDC circuit of the drives, to protect them from welding noise.
    2. Wago CanOpen - When first powered up, the nodes were throwing an error onto the bus, then working fine thereafter. It turns out the node remembers the IO configuration that was connected to it the first time it was powered on, and if it sees different, generates this error before going to Operational state. Can be corrected by writing "save" to the appropriate register via SDO and CanOpen configuration software.
    3. Numatics CanOpen - After powering up, the nodes would not respond to or generate any PDOs. I could see them in PCAN (software) and everything was right - operational, PDO length reflecting the physical IO attached, and no errors on communication, but also no action from them in response to input being tripped, or output being commanded.
    I grabbed my original test unit and checked it, and made a suprising discovery - the test unit had all 8 bytes of it's PDOs configured. This, regardless of the fact it only had two bytes each worth of IO. I used PCAN to manually configure the PDO on the nodes of the machine, and it all came to life.
    It seems that despite the Numatics node automatically detecting the IO attached, and automatically configuring it's PDO in response, it will not recognize or generate a PDO of any kind if it is, in fact, less than 8 bytes in length.
    Also of note, while the corrected setup is retained, if you get a bus-off error, it will force the node to reconfigure its PDO back to defaults, ie automatic detection again. It has to be corrected manually again to correct.
    4. Motoman - ah, motoman. The CanOpen cards I ordered were bad from the box. Turns out that batch had known firmware issues. After several phone calls and some frantic rushing around, converted the robots to my fallback position of Modbus TCP.
    Lesson - if you are trying to do CanOpen with Motoman, at least in the US, don't. There's zero support for those cards and the cards themselves are questionable at best. Unitronics supports several protocols, just pick a different one for your robots.
    5. IPD Dalsa vision system - nothing but kudos for these guys. I've using the VA31, and it runs terrific. One word of advice, use the hardware trigger input, it's just so much simpler than trying to trigger the image aquisition from modbus. Leave the data to modbus and trip the camera with a relay.
    6. Unitronics - I replaced a Pentium 3 PC running Entivity Steeplechase. It included $16k worth of proprietary hardware, including a Sherlock vision card, two Motion control cards, and a devicenet card, all obsolete, all nearly impossible to obtain.
    I replaced that mess with a Vision 570 PLC, and a combination of CanOpen and Modbus TCP. The PLC cost less than any single component of the original PC based system - if you could even find them anymore.
    That's all for now. Thanks for reading!
    TM
  7. tmoulder
    Caution: This approach can be risky. Analog voltages greater and 15 VDC can fry an analog input on an E1B module. Use with caution, and at your own risk.
    I had a project where I needed to use a potentiometer with an E1B snap IO to measure an angular position. The problem I ran into was resolution. With 10 VDC applied to the pot, and the E1B resolution of 1024 units for full sweep, the portion of the pot I needed was only seeing 22 units.
    I had an idea - I put full 24 VDC to the pot, then positioned the pot physicially so I was at the lower end of it's physical scale. This gave me 10VDC at slightly less than half of the pot's travel, which took my measured sweep from 22 units to 92 units. Huge improvement.
    The drawback was - there's 24 VDC on the pot, and E1B inputs fry at 15 VDC. If someone replaces it incorrectly, gets to playing around with it or even a wire comes loose, poof.
    So to protect the input, I hunted high and low and came up with this circuit.

    It uses a 10k resistor in series with a 12V zener diode, all available at your local Radio Shack. It shunts the current in such a manner that the input can never see more than 12 VDC even with a full 24 VDC coming from the pot - overscale, but below smoke point. The zener begins regulating at 11.4 VDC, and below that, behaves like a regular reverse-biased diode.
    Hope it's helpful!
    TM
  8. tmoulder
    This is a little Modbus routine I wrote to connect to one remote node, in my case a Dalsa IPD vision device. It's not designed to connect to several devices, just a one-to-one such as my camera setup, a single servo drive or VFD.
    As such, it is really optimized for maximum communication to that single device. The module reads the vector of addresses from the slave constantly, as fast as possible. Writes only take place when a value in the Tx Vector is changed. So the PLC always has the freshest possible data in the fastest possible manner.
    On the HMI Side, I collected about a dozen different status bits into two message objects, one for the Ethernet adapter and one for the socket.
    Special thanks go out to Ash Neilson, who was a tremendous help on getting the serial variation of this running last year.
    If you look at the source and find yourself wondering why there are two Socket 3 Busy bits, check out the conversation here:

    I hope you find it useful!
    TM
    Edit: forgot something, added rollover for the RHR / PHR counters and an error count.
  9. tmoulder

    FOSS Logic

    By tmoulder,

    Lately, I've been twiddling around with Linux, and learning about it's history. I've been extremely impressed by what a group of people can accomplish with some collaborative effort and a willingness to share that effort.
    I'm no PC programmer, but I am a PLC programmer, and over the years I've developed a number of importable code modules I use in my programs. In the spirit of shared effort, I'm going to make some of these modules available to the forum.
    These are modules I've personally used and extensively tested, but I make no guarantees about how they will work out for somebody else's application. I try to make them as general purpose as possible, given that I wrote them for my own needs.
    Lastly, in the spirit of Free and Open-Source Software, I ask that if you make a neat improvement to the module, share it back with the rest of us, so everyone can benefit from the spirit of collaboration.
    Thanks,
    TM
  10. tmoulder
    Greetings all!
    This program has been floating around in a couple of forms since before Christmas. Essentially, it is a program to create a CSV file on an SD card, and incorporates a data table as a buffer to prevent data loss if the card is removed, or writes come in too fast. This latest revision includes logic to create column headings at the top of the spreadsheet automatically when a new file is created on the card.
    Instructions for use and importing into an existing project are in the Readme file in the zip archive.
    Enjoy!
    TM
    SD Card with Buffer Rev 2.zip
×
×
  • Create New...