Eric Apperley

MrPLC Member
  • Content count

    33
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Eric Apperley

  • Rank
    Sparky

Contact Methods

  • Website URL http://

Profile Information

  • Location Christchurch
  • Country New Zealand

Recent Profile Visitors

1289 profile views
  1. Serial Bluetooth interface

    Some thoughts .... may not be relevant but anyway here goes ... I'd be surprised if the PROMI-SD has that much affect on your download rate., but I don't have the figures in front of me for the latency of the PROMI-SD driver and hardware. You could probably obtain those specs direct from the original manufacturers of the Promi-SD devices. In our tests last year with a pocket PC running bluetooth serial at 57600 bps communicating with a CJ1M with Promi-SD adapter we were able to download all 64K words of DM memory in under 60 seconds. That was with the verbose transfer method of FINS protocol encapsulated inside Hostlink protocol and with a "virgin" ("out of the box") CJ1M and using the serial (not peripheral) port. Toolbus protocol transmission is in binary not hex ASCII form and has minimal overhead in terms of headers/trailers so should be faster for you in practice that I achieved. I must state that I did, however, notice an increase in download time when I changed to another variant of CJ1M that had been previously used on a site. I wonder, therefore, whether there's a PLC setting that might be affecting this? I vaguely recall discussions last year with the agent on some settings in the CJ1M for improving background servicing of the serial port. There is one check you could do to isolate whether its actually a Bluetooth issue or a setting in the PLC or PC. In effect the Promi-SD and the remote Bluetooth adapter on the PC act like a virtual serial cable - the settings in the PLC and PC should be the same (other than the COM port setting in the PC software). What is the comparison in download times when you switch back to a standard serial cable? Stop-start transmission can be indicative of problems in not processing the receive buffer frequently enough or not filling the transmit buffer fast enough to sustain high transmission rates. A serial analyser placed on the serial port between the PLC and Promi-SD may be enlightening - i.e. the delay between the end of the message received by the PLC and how fast it starts responding, also the inter-character delay in the message transmissions from either end, whether message retransmission is occurring due to error or time-outs, etc. Eric
  2. ASCII and CJ1G

    Yes, I did wonder why the CPU serial port wasn't being contemplated instead os the extra module. Thought maybe I'd missed something ...
  3. Need opinions

    No problem. Ethernet is a sensible approach to expansion. The short term cost of buying the ethernet modules will no doubt be recovered by the savings in software development and ease of maintenance due to the standard architecture. Good luck with the project. Eric
  4. Need opinions

    As Scott pointed out we have done exactly that on a PDA using Bluetooth (plus other functions). The application program for the Windows CE PDA was written in .NET and communicated via a virtual serial port under Bluetooth using both Hostlink and FINS protocols. The application was written for an OMRON customer however the project was cancelled so it never proceeded to completion, however extraction of data from the PLC DM Memory was successfully demonstrated to the Customer by the local OMRON rep. I'll try to give you a balanced perspective. Some thoughts, although I'll probably turn you off the concept ... Advantages of PDA Approach: ---------------------------------- a) The PDA user interface is clearly better suited to a non-technical user (not sure whether this is an issue in your application if you will be the one using it). Basically its a slightly crippled Windows user interface but easy to assimilate for most users these days. b) PDA + Promi-SD Bluetooth Adapter cost may be cheaper than the OMRON handheld? Not sure on this ... PDA's have come down in price and up in capability for the lower-end models. c) The PDA can be used for other tasks, its not dedicated to just communicating with the PLC. However, this might be a disadvantage for users who like to fiddle with things ... d) Using Bluetooth means you won't damage/wear out the connector on the PLC over time however you'd either need a Bluetooth adapter on the scanner too plus some mechanism to tell the PLC what device to expect on the serial port OR perhaps use the Peripheral Port for the scanner? The PDA is quick to "connect" - no cables to plug/unplug, just tap on a button on the display. e) Can be used remotely from the device - I've tested in commercial buildings up to 10m without issues, however range will be reduced somewhat in an electrically-noisy industrial environment. Disadvantages of PDA Approach: -------------------------------------- a) Limited user interface available on the PDA - small amount of "real estate" (screen) therefore difficult to display much. Also no keyboard per se (although some PDAs do have tiny keypads incorporated). Relies on tapping objects displayed on the screen or use of the "SIP" (soft input keypad) to enter values. "Do-able" but not as nice as having a decent keypad. b) PDA's are not ruggedised, therefore a PDA may not be suitable for the environment (depends on your application and the class of user). c) The PDA may be cost effective compared to the handheld but the software development costs for the application have to be amortised over the quantity of units sold. That's an issue if this is just a "one off" application. d) The PDA has a battery that needs to be kept in a charged state. I don't envisage this as an issue for the OMRON handheld since it probably extracts power from the PLC serial connector pin allocated for that purpose. e) Although the PDA's OS is in ROM its still a Windows device, i.e. reboots are sometimes necessary, depending on what people do with it! However, I have also had Linux running on a PDA off the SD card - very impressive and extremely stable, but I haven't had the time to write and test a program to operate on the PDA under Linux. Generally your proposal of cable swapping sounds a bit messy if there's going to be lots of occasions where DM memory values need to be tweaked. If you only need this scheme for initial setup then not an issue but otherwise maybe a ultra-light notebook might be better (although I understand that they're not cheap). Anyway, that's my "tuppence worth" ... Eric
  5. CJ1M Ethernet using .Net

    For those that are interested here is my response to a question raised in my "Personal Mail" on this forum. I've quoted the original question first. Jacco, My work on the PDA was using Bluetooth and serial communications. I used both FINS and Hostlink commands but via a virtual serial port over Bluetooth. I didn't do any socket programming on the PDA as the PDA did not have WiFi capability. To use Wifi you would need to use "sockets" and either TCP or UDP. I have worked with sockets on a desktop PC to communicate with a CJIM PLC and it was fairly straightforward after I'd read the OMRON ETN21 manual and done some research on ethernet client and server socket programming in Delphi or .NET. I don't have the prototype code at hand right now to be able to send to you and unfortunately I had to return the loan CJ1M so I can't continue that work right now. There doesn't seem to be any commercial demand for such programming but I am happy to produce a brief tutorial with code if someone wants to loan and ship me a CJ1M with ETN21 adapter. As I recall there are some OMRON program examples either in the manual. In summary the main requirements are: a) setting up the node number and TCP parameters etc on the ETN21 unit - you should be able to "ping" the unit from a PC once this is done correctly, subject of course to the usual networking routing parameters. b) reading the OMRON manual and understanding both the protocols and the ethernet unit : W227_E1_02_FINS_Commands_Reference_Manual.pdf W342_E1_09_CS_CJ_Communications_Commands_Reference_Manual.pdf W420_E1_03_CS1W_ETN21_Users_Manual.pdf W421_E1_02_CS1W_CJ1W_ETN21_Operation_Manual.pdf W420 is probably the most pertinent but you'll need to also understand the FINS commands. c) Read articles such as: http://www.devarticles.com/c/a/C-Sharp/Soc...ng-in-C-Part-I/ http://www.devarticles.com/c/a/C-Sharp/Soc...-in-C-Part-I/1/ Hope this helps. Eric
  6. Read from a memerycard (CJ1M-CPU11)

    Are you wanting a program to run on thew PLC or on a desktop computer ?
  7. CITECT not communicating with CJ1M

    Guys, thanks very much for the input. I was afraid that I'd probably have to install the FINS Gateway to get this to work (yet another darned bunch of entries in the already bloated Registry!). I presume that I use the version of FINS Gateway from the CITECT DVD? Pity the CITECT manual or help or site didn't cover this setup. I must confess that the OMRON section of the CITECT driver site was a bit confusing. I'll try this out over the weekend. I'm a bit perplexed as to why I need a routing table in the PLC just for this wee setup when : a) there's only one PLC and its on the same network address as the CITECT PC b) I don't currently need it for any other application However I'll be a good Kiwi and follow the advice (and play later...). Eric Here's the tag - pretty basic I'm afraid. It's intended to display the contents of D Memory at 500 Hex.CITECT_Tag_Details_for_Learning_Session.doc
  8. CITECT not communicating with CJ1M

    I've recently obtained the CITECT v6 DVD from the local distributor with a view to familiarisation as I've never worked with the product before. I have read through an old training manual for V5 and have a CJ1M with ETN-21 Ethernet adapter which I want to connect to CITECT as the external I/O device for training purposes. I have successfully installed CITECT and configured the ETN21 on the PLC. I can ping the PLC from the PC and can also talk to it from my .NET programs using either using TCP/IP sockets or hostlink serial comms. I can also communicate with the PLC from CX-One using either hostlink serial or ethernet. However, I can't seem to get CITECT to communicate with it using either a serial or ethernet connection so I figure I've got something basic wrong in the CITECT config. I note that there is no CJ1M driver listed so I've selected the OMRON CS1 Ethernet 2 driver. The symptom is the "#COM" message that CITECT displays on the graphics page and the complete lack of ethernet comms with the CJ1M. I've basically just added a display field as a variable tag on a page in CITECT that is supposed to display the contents of DM500 in the CJ1M. That location is incremented once a second by a time in the ladder logic PLC program. I've attached screen-shots of relevant data in a MS WORD document. Any thoughts from CITECT PLC gurus as to what I'm doing wrong here? Eric CITECT_CJ1M_Setup.doc
  9. Remote access to PLC

    1. As the 1st respondent said - keep it simple! 2. If you have to go the radio way, what range are you requiring? We've done .NET Pocket PC bluetooth to PLC (could equally well be SmartPhone bluetooth to PLC) but the development is NOT trivial. We've invested a lot of hours in that work and its certainly not for the faint hearted! The bluetooth dongle adds a cost to the PLC - that may well not be acceptable in the scheme of things....
  10. Blowing CJ1 Comm's Port...

    1. Are all the plug packs (power supplies) plugged into the same UPS as the PLC? 2. Can the timing of these incidences be traced to either lightning strikes or major power surges (eg trees falling on lines or major S/C or O/C conditions on the power network) in the area? Often these types of failures are related to differences in earth potentials, especially under fault conditions. With RS232 the TD and RD signals are of course referenced to SG (signal ground), i.e. unbalanced signals. SG should be electrically separated from the FG (Frame Ground). Does the UPS actually provide surge protection when running on AC power? Some of the older/cheaper models don't... Check: 1) Earthing - watch out for earth loops! Don't earth SG to FG! 2) If the incidences can be related to power disturbances add qood quality surge protection and filtering. You can do this yourself by fitting varistors P-N, P-E, N-E plus a small power line filter module AFTER the varistors. The varistors (or the Phase line itself) need to be fused as varistors go S/C on failure! The best solution would probably be optical isolation as pointed out by others.
  11. Promi-SD202-OA

    Technically it is achievable - by using a PromiSD adapter at each end you effectively have a transparent serial link. This is accomplished using the Serial Port Profile of Bluetooth and creates "virtual serial ports" on each device with the adapter fitted. That's the easy part - configure the BT adapters and PLCs with the comms parameters. However the real work is writing the serial comms programs as (as I understand it) the Controller Link units currently do the comms work for you - refer to the statement in the .pdf document on the Controller Link unit: "Data links do not require the use of communication programs on the PC (CPU Unit) or IBM PC/AT or compatible computer" I'm very familiar with setup and using the PROMI-SD bluetooth adapater for serial comms from a computer to PLCs but I have never done PLC to PLC communications myself, however there will be plenty of others who have on this forum. If you do proceed along the Bluetooth path you will find a setup note by Jay Anthony for the Promi-SD device on this forum. In particular you'll need to set the CPU serial comms parameters for 8 data bits for that adapter. Eric
  12. Bluetooth serial port

    Bob, Sorry I don't think I answered the real question - apologies for that. Several points which may help. 1. Some USB Bluetooth devices do support two virtual serial ports, not all. In that case you can "talk" to two serial devices concurrently/independently via their different (virtual) COM port labels (e.g. COM14). Two "COM port" assignments will be made to the Mitsumi device at installation of the software. These assignments are stored in the registry. 2. The Bluetooth stack software will determine which remote Bluetooth device you are going to to connect to. Often it is the LAST remote bluetooth device it connected to, but some applications will present a Bluetooth browser screen in which you can manually select the remote device (e.g. the HP iPAQ, which uses the Widcomm Bluetooth stack, always presents a browser window whenever you "open" a virtual serial port via the software application). 3. The stack will have provisions for the remote device to be selected programmatically, but the problem is that most software applications (e.g. CX-ONE) don't provide that facility so pairing a remote device to the virtual serial port is the only way or relying on the "last device connected" facility. 4. If the PLC's are networked on a single network then you'd only need one Bluetooth "connection" to communicate with any PLC on that network. That would only require one dongle at the PC end and one PROMI-SD fitted to a PLC connected to the network. The correct routing would obviously need to be set up on the PLCs for that to work. 5. I haven't tried it but you could no doubt use the manual "browse" function supplied in the software supplied with the dongle to connect to a particular remote device and thus set a remote device as the "last" device connected to. IN SUMMARY It can be a bit confusing but remember that there are two addresses to be selected if you use virtual serial ports over Bluetooth: a) the COM port (e.g. COM14) at the PC end - you will normally select the COM port in the PC application software as though you were connected by a serial cable. b) the device address of the remote Bluetooth device - this is where the problem lies. Most PC applications don't have any facility for setting this, e.g. CX-One software. The only answer is pairing or the "last device connected"
  13. Bluetooth serial port

    I do not have the OMRON "kit" as you described it (I received just the box with th Intium Promi-SD device from the local OMRON office), however I have done a lot of work with the PromiSD device (PDA serial via bluetooth to PLC). My PromiSD box contained the programming software for the device and both adapter and power supply cables. If you connect it to a serial port on a PC using the supplied DE-9 to DE-9 adapter cable (note that the Promi-SD device has a pin-out which matches the non-standard pin-out on the CS/CJ serial port) and install the Intium programming software on the PC then you can program the device and create device pairings as required. You can even pair it up to a bluetooth cellphone if you're crazy enough.... Note that you don't have to do pairing unless you really need higher-level security. The PLC has security anyway so you're best to use that security and set the PromiSD up as simply as possible, certainly in the initial stages of familiarisation. Here's the plan: (NB "PC" used in the discussion below is a "Personal Computer") 1. Attach the PromiSD device to a PC serial port using the supplied adapter cable . 2. Attach the supplied power cable to a USB port on the PC and to the PromiSD device and turn on the power switch on the PromiSD device. 3. Depress the reset button on the PromiSD, located right next to the "ON" position of the PromiSD's power slide switch (you'll need the end of a paperclip or similar to reach inside the enclosure to the button). This will reset the PromiSD device to its default parameters: - Serial Port = COM1 - Baud Rate = 9600 - Parity = None - Stop Bits = 1 The "Status" LED will colour will change to orange. 4. Install the PromiSD software on the PC. Start the PromiWIN program. 5. Promi-SD should automatically detect the device and display the Information screen showing data such as: - Device Name - Device Hardware Address - Current Mode = MODE0 - current Status = Standby - Security = Don't Use - Encryption - Don't Use - UART Settings - as above in (3) 6. Click on the "Device Setting" icon in the LHS panel. 7. Make changes as required - suggest the following: - Operation Mode = Mode 3 => Allow Bluetooth devices to discover and connect to the device - Change the "Device Name" to something meaningful. For example, use the PLC hostlink unit number preceded by the letters "PLC" (e.g. "PLC02") - Leave the "Authentication" and "Encryption" checkboxes unchecked. - Do not enter a password at this stage. Click on the "Apply" button. Wait until the confirmation message "Configuration Applied" is displayed. The "Status" LED should now be green and flashing. 8. You can now browse for other devices (and connect to them) by clicking on the "Connection(Out)" icon in the LHS panel. Other Bluetooth devices will only appear in the browser window if those devices have been set to "discoverable" mode and "all devices" (as opposed to "Paired Devices only"). Note that you can still discover other devices irrespective or whether their Serial Port service is enabled. I don't have a Mitsumi device but it probably works very similar to other USB devices in that there should be a menu option to discover other devices. You should be able to "see" the PLC dongle (the PromiSD) at the PC end using the Mitsumi software. I've got no idea why they would tie the USB dongle to the originally installed port. That doesn't make any sense to me at the moment... Hope that helps. Eric
  14. electronic scale ith RS232

    Pawel, To summarise, you will need to get the following information about the Scale from the manual, documents on the manufacturer's website or the distributor/supplier : 1. Hardware Interface Connector - DB25, DE9, or other non-standard RS232 connector, etc. Gender - male or female Pin allocation - - DTE or DCE, or modified version Hardware handshaking - RTS/CTS etc Standard - RS232, RS485, etc. This, along with the PLC model and which PLC port you use (e.g. Host, Peripheral, etc.) will determine the cabling. 2. Communications Interface Data Rate (bps) (commonly, but erroneously, referred to as "baud") Number of data bits per character - 7 or 8 Character Parity - Odd, Even, or No Parity Number of Stop Bits - 1, 1-1/2, or 2 Handshaking - Hardware (RTS/CTS) - Software (XON/XOFF) - Both Hardware and Software - No Handshaking Normally these are configurable on devices but some may not be. You need to know how to configure them in the Scale or what the default values are. This information is required to set the PLC's communications parameters - the PLC's communications parameters must match the Scale's parameters. 3. Communications Protocol This could be proprietary or standard (eg. MODBUS). If the protocol is a standard protocol then the job may be easier depending on which protocol it is. The protocol will generally describe : Message Framing/Format (for both Transmitted and Received messages) - message block length - maximum size of message blocks - addressing - source and destination unit addresses, if used, and format - start sentinel (start of message character) - message block terminator (CR or CR + LF or other - error status - etc. Frame Integrity Checks Generally a "checksum" of some sort - CRC - CRC16, CRC32 - XOR across message characters - other Which characters are included in the check (i.e. start sentinel?, Data Format - ASCII or Biinary Timing Time from receipt of command from PLC to start of response Inter-character timing (not usually an issue these days) etc. Mode Master/Slave etc. - for this type of device the Scale will probably be a Slave polled from the PLC Data Representation Data Element description, for example : - Date - Time - Tare Weight - Weigh Number - Weight - Information entered from scale keypad - etc. Data Type and Size for each Data Element: - Date/Time - Floating Point (Real Number) - Short or Long - Integer - Byte, 16-bit Word, 32-Bit Integer, 64-bit long, - String (number of characters) - BCD - Hex ASCII - etc. Hopefully, as PDL suggested, the Scale uses a standard protocol that's easy to implement in the PLC (because someone has already done it) then all you need to worry about is processing the data elements specific to that scale or application. Initially I'd suggest that you reply to the forum with the detail of : - What PLC and PLC modules you are using/have available - The manufacturer and model of scale - Any details (as described above) relative to the Scale that you already have the information for Hopefully that will get you started and reduce the number of posts you need to create the solution. Eric