DesertDog

The 200 series is indeed a easy to use powerful PLC. I believe Siemens bought this system from a US company. If you need more power you have to step up to the 300 series. It's not at all like the 200 series and although it is powerful nothing about it is simple.

Caro, Check PG/PC Interface. Make sure you have PC/PPI Cable(PPI) selected, check the baud rate, AND look under the Local Connection tab to make sure USB is selected.

It is fast and versatile but as with many PCMCIA cards it's easy to break the connector for this expensive card and the adapter that plugs into the card is large and heavy so just letting it dangle from the laptop will damage the connection. I find the size a problem because I often do field service where my laptop is on an overturned bucket or similar not having a large workspace to let the connector set on.

I have used several of these without any problems. I don't know how you formated it or what the recomended procedure is but mine have always come pre-formatted. I do know that although a standard SD reader will see these cards they will claim they are not formated because Siemens uses a non standard format. Formating one of these as a standard SD will prevent the CPU from being able to read it.

I have done this but it's as much an issue with the laptop as the device so your results may vary. I have also used the USB PPI cable PN# 6ES7 901-3DB30-0XA0 with no problems.

There is a OB100 in Siemens that only runs on the first scan before starting to cycle OB1. This is intended for all such setup functions instead of using a first scan bit. I prefer the style used in most other PLC's so my OB100 only has: SET S     "First Scan" S     "Always On" R     "Always Off" SAVE and the last line in OB1 is SET R     "First Scan" S     "Always On" R     "Always Off" SAVE This can also be done in ladder but it is quick and easy in STL so it's one of the few instances of STL I use. Now if there was a way to get Last Scan such as GE has.

If it's pulses unless the frequency is very high I just read the time between pulses and figure the RPM from that.   Pulse          P          One Shot ----| |---------| |-----------( )  One Shot ----| |------------(Divide 600 by Timer Value) ------------|-----|--             | TMR |  One Shot   | 0.1S| ----| |-----|Reset|             |_____| This will find the current RPM and reset the timer with the leading edge of the pulse. Accuracy can be adjusted by moving the decimal And/Or creating multiple pulses per revolition and adjusting the math accordingly.

The Siemens FM 350-2 counter can read a pulse and report it as a total count, frequency, speed, etc. This is an 8 channel card but they may have smaller/cheaper options. This is a standard card that connects to the PLC rack but you can place it on an I/O rack with an ET 200M (IM 153-1) DP Slave to make it accessable through Profibus along with any other I/O you want.

That's how I would do it. I would use T's as they are intended for "Temporary" use but it doesn't really matter. If you are worried about using up values, reuse the bits as long as you're careful of the scan order: Move %r into %m's(or %t's) Link %m's into %q's Move New %r into same %m's link %m's to new %q's Etc. As long as the %r is reloaded into the %m's before each output this is no problem.

Here's a link to the S7 CP 343-1 Manual Look on page 7 (A-7) for links to other useful manuals.

Here's the Send/Recieve demo. This requires some code in the PLC and lets the PLC control the communication as opposed the Fetch/Write where no PLC code is needed but the Application needs to control the comunication. SendRecvDemo.ZIP

I recomend using a CP 341-1 and exploring the native TCP/UDP options. I've done the PLC end of this in the past and interfaced with a java app and a c++ app using only windows COM objects and socket connections. Using the Passive Fetch/Write mode you don't even have to have the PLC running to read/write data. I've attached a (somewhat buggy) VB Fetch/Write example and I'll follow with a quick post with a send/recieve VB demo. fchwrtdemo.zip

I know you can pull data to/from a CP-343-1 directly using TCP/UDP & windows sockets bypassing the need for an OPC server. If this sounds like a better option for you I can get you some documentation but I also know 0 VB. I did the PLC side for this while the customer supplied the VB.

I once found that after upgrading from and A1S-S1 to a AH??? a program (in ladder) acted differently. After much troubleshooting I found that a coil set/reset in multiple places was held to the first condition instead of last as if the scan was running back wards. That was the last Mitsubishi project I was on so I don't know if it was just a short term bug or what.

MEDOC willalso program through the RS-232 port but there is some minor function loss, you can't force anything for instance.