Duffanator

I'm looking to cut down on wires AND cost. CC-Link is not cheap

Hey all, Has anyone had any experience with the Phoenix Contact FL IL 24 BK-PAC Modbus TCP/IP modules? Do they play nice with the Mitsubishi Q-series Modbus TCP/IP modules? I would like to have some remote temperature monitoring stations and these are cheaper than running wires but I want to make sure they would work ok first. Thanks! P.S. Here is the PDF for the Phoenix Contact module: http://select.phoenixcontact.com/cgi-bin2/pcdwlfile3.sh/db_gb_fl_il_24_bk_6155_en_03.pdf?fct=dwl&from=〈=en&UID=2862314&prodid=&asid=505612

Do you just want to see if clear film is where it should be or are you looking for a registration mark?

You should also take operating environment into account as well. If the end user location is going to be very dusty, hot or a washdown environment then I can tell you from experience that the "cheaper" plcs, Automation Direct, EZAutomation, Wago, won't hold up. You may as well bite the bullet and put a more hardened, expensive PLC in there because it will save you money in the long run. If it's going to be a dry cooler environment then those PLC's will be fine. Just some advice from experience!

Hey all, Does Mitsubishi make a Ethernet I/P communications module (preferably for Q or iQ platform)? I've found things like MC protocol to Ethernet I/P gateways and things like that (http://iccdesigns.com/Merchant2/merchant.mv?Screen=PROD&Store_Code=ICC&Product_Code=eth1000) but nothing directly from Mitsubishi. Has anyone heard anything about a module like this in the future?

One physical network, multiple VLANs. VLANs are assigned on a port by port basis by our network administrator. Usually I'll run one ethernet line out to the machine I need network connectivity to, IT will assign a port on the switch closest and give it access to the 10.101 VLAN. On the machine side I put a cheap Phoenix Contact industrial Ethernet switch (unmanaged) in the machine control panel. I will connect the PLC, HMI and whatever else on the machine I want network connectivity to that switch. Two benefits to this: 1: If the network goes down for some reason the PLC and HMI can still communicate with eachother, so the machine won't be down. 2: The cheap switch in the machine keeps a lot of traffic off of the main network switch. All HMI <-> PLC traffic is routed by the switch to the correct port by MAC address and not back to the network. Make sure this is a SWITCH and not a HUB! If you put a HUB in it sends every packet it gets from one port out on all the others and you'll flood your network with all kinds of stuff. The Phoenix Contact switches are pretty cheap ($90) so it's worth it to put those in for the added benefit. I don't know the specifics of the network side, our network administrator takes care of all of that. I just tell him I need to go back to such-and-such electrical room, how many IP addresses I'll need, and a description of what each connected device is. He takes care of the rest, then I hook it up when he's gotten the switch configured the way he wants and we test.

That's what we do at our plant. We have a "machine" network of 10.101.x.x. That is broken down further into different types of PLC's, for example, 10.101.20.x are all Mitsubishi PLC's. 10.101.1.X is all Opto 22, 10.101.50.x is all Allen-Bradley so on and so on. Then I have spreadsheets for each subnet that I keep track of all of the PLC's and HMI's. I can look at the spreadsheet and find exactly what I want to know is seconds because I know where in the spreadsheet to look. The more organization you can do up front the easier it will be in the long run. Keep your IT department in the loop at all times! If you add things to the network randomly then they can't make changes correctly to optimize the network, or even worse they will reassign IP addresses without knowing you're in a range and then there are duplicate IP's and time is wasted trying to figure out what's going on.

Cool, this is very helpful. IEC is weird if you're used to standard ladder!

I use it to remote monitor a machine, but I only use it in the plant. I don't access from outside of the plant. It does come in handy when you want to look at an error or what the machine is doing from down in our shop. I wish Mitsubishi would do that with their HMI's.....

Nevermind, I figured it out. Instruction JP.ZNWR

Hey all, Is it possible to write D register information to another CPU station via Ethernet without using the buffer communication commands? (ZP.BUFSND and ZP.BUFRCV). You would think that if you set up the Station No. <-> IP Information settings then there would be a command to send information to a station number just like an HMI does. The only thing I can find instruction wise is "j.write" but I can't find any information on this command anywhere. Does anyone know where to look or if this is even possible? Thanks!

Wow... you still have F2 CPUs? I would recommend you get rid of that as soon as possible. If I remember correctly you couldn't program the F1 or F2's with Medoc, you needed a programming module that plugged into the face of the PLC. I'm not 100% sure of that but I remember dealing with that issue once before a long time ago.

What model PLC is it? From your part numbers it sounds like you're dealing with a Q-series PLC. In that case, you need a SC-Q programming cable. There isn't anything special about it, it's just straight 232 9 pin to mini-din 6. The USB cables are standard USB cables that you can get at a radio shack if you need. Don't spend the extra money buying them from Mitsubishi. If the PLC you are trying to connect to is a FX or A then you will need a SC-09 programming cable, which is more expensive because it has a 232-485 converter built into it.

You can only have 1 loadcell directly connected to the loadcell module, but you can have more than one connected through a summing card. I just recently completed a project that used two cards (one for a entrance scale and one for an exit scale) to find an injection % value. The old system was one scale head with a summing card, but by using two Q61LD modules it was like having two seperate scales on one PLC. This had the added benefit of keeping the scales seperate for easier troubleshooting and calibrating. I believe (depending on the CPU) you can have up to 64 modules if you wanted. It could even be possible to take loadcells, say for a floor scale, back to 4 different cards and do summing in the PLC. I don't know why you'd want to, but it's possible. :-P

Has anyone noticed that programing in Structured Text is very unsatisfactory? I was writing a function block today in Structured Text and I was about 25% of the way though and it stopped me and said I was out of memory. When I compiled it it was over 2,000 steps for a program that in, say Opto 22, would have been about 4Kb out of 6Mb. How is that possible? Am I doing something wrong or what? If I wrote the same program in ladder it would have been way less than half that many steps. It doesn't seem like it compiles very well. Has anyone else had any experience with it or have any tips that makes writing in it any easier?

No offense, but when I spend all day Saturday trying to get code to work that was recommended by you and then (apparently incorrectly) assume that since you recommended this way of writing the code that you would know why these specific problems may be happening and ask you why, the answer I get shouldn't be that the way I'm trying to figure out what's going on in the program is a "Voodoo" practice and I should start over. My original ladder code, while long, WORKED! I don't appreciate being ridiculed for writting code that works and being told that it could be much more efficient if I do it such and such a way and then waste a week of my time rewritting the program and then trying to get that to work, and at the end of all of that being told that I should just start over.... If you want to tell someone that they are an idiot and don't know how to write PLC programs, then the program you tell them to write better dang well work or at least be feasible. All you did is waste my time and delay my project. I'll go back to my original code and continue from there.

Inntele, Do you mind taking a look at my cutoff programs starting at step number 193 and see if it makes sense to you? I took what you did with the other part of the program and did something similar to step through the available pushers that are selected. Just want to make sure I am doing it right. Thanks! FPRibLine20100125.zip

I've used the QD62 high speed counter module before with very much success. I used it on a roll-pack packaging machine and the ring counter function was very usefull for keeping indexing right on. It's made even easier to use with the GX-Configurator (CT I believe....) for that module. Almost no ladder programming to set it up. Maybe that's something you would be interested in.

hmmm... that's very interesting. I had to run it through in my head a few times until I figured out what you were doing but that is very nice. That will free up a lot of steps. Thank you for the help!

That isn't the same function at all.... In my function block it will activate 1 pusher at a time from all available pushers. So, for instance, say I have pushers 1,3 and 5 enabled for cutoff #1. Then it will activate pusher 1 for the first rib, then pusher 3 for the second rib then pusher 5 for the 3rd rib, so on and so forth... actually now that I think about it I think it's wrong but that's what I was trying to do. Each cutoff that is enabled can have any of the pushers assigned to it, so there may be 1 pusher assigned to it or there may be 8 pushers assigned to it. I needed to step through each pusher that is enabled. The code you posted will just activate any pusher that is enabled. The other problem I had was that once I step through the pushers they are all a different amount of "counts" (Encoder pulses) away from the scale. So when I assign a rib a pusher to be diverted at I also have to assign that rib "slot" a number of counts until divert and the time that that pusher needs to divert. There can be up to 8 (I put in 10 slots just in case) ribs on the line at a time so I need to track the weight of each rib, what pusher it's been assigned and what count that the rib is currently at. This would be easy if they wanted only 1 pusher per weight range, but they want it to be dynamic. Able to be changed at any time and the ability to have any number of cutoff/pusher combinations.

I don't doubt that at all. But considering how I've had to teach myself how to write PLC code, I think I do pretty good.... Still, the question remains. If I write a function block that is 456 setps long and put it in the program 8 times and it comes out to over 5,000 steps then why use a function block at all? Isn't that supposed to be one of the advantages to function blocks? If it uses the same amount of steps (or more, it seems) then I could just as easily write it in ladder and just integrate it into the program. I understand that the PLC has to map the M contacts to the input and output variables but that shouldn't take up steps.... that should just take CPU time. Since the PLC scans each program from top to bottom (it's not scanning multiple programs simultaneously) then why not move the variable inputs and outputs into the function block when it gets there and then perform the function block code.... If I load that program into the PLC and then upload it the function block ladder code is there in each program. Seems very wasteful to me....

I started over and wrote a smaller function block that just takes care of stepping through available pushers and when I compile the function block it says it's 452 steps big. Ok, but when I check the size of the structured file when it sends it to the processor it says it's 5,456 steps..... Not sure what the deal with that is. I have a screen shot and I'll upload my (unfinished!) program if anyone wants to look at it. STStepNumbers.bmp FPRibLine.zip

Hey all, This is a home issue and it's being a pain in the but... I got a Windows 7 Toshiba Netbook for christmas from my lovely wife (yay!) and I joined it to my network at home via a wireless connection. (Not sure what the network card is in it but the wireless router is a Netgear WNR2000) It worked great for the first few days but then all of a sudden I couldn't connect to any of my other computers with the netbook. If I go into the network explorer it only shows my netbook, yet if I go into the network explorer on any of my other computers (Windows 7 desktop, Windows Vista Desktop, 2 Windows XP Netbooks and a Windows XP Desktop) I can see everything INCLUDING my Windows 7 netbook that won't let me see any other computers.... Makes no sense to me. I have trolled the internet and tried adjusting all of the Windows 7 networking options to no avail. Today I was playing with it and found something interesting but makes absolutely no sense to me. If I open a command window and ping one of my other computers by name it says it can't find it, however if I ping it by IP address (they are static IP's) it finds it fine and then..... it magicly appears in the Network explorer! I can also then ping it by name. WTF? Has anyone ever run into this problem before? I have another windows 7 computer and I don't have this problem. I don't know if it's because it's on the wireless network or what. Any help would be appreciated, I'm a networking retard! Thanks!

Thanks for the reply, Bob. That pointed me in the right direction. I checked and deleted the ARP cache and tried again but it didn't work. I then searched for ARP related networking problems and eventually found this: http://www.sevenforums.com/network-sharing...ut-problem.html This was very helpful and I ended up tracing the problem back to my router, interestingly enough. Apparently the router also has an ARP table that can be corrupted when something like a netbook or laptop goes into sleep mode and it's trying to communicate with it. I rebooted my router, cleared the cache on my netbook and then it started working perfectly. Thanks for the help, Bob. I wouldn't have found that on my own!

We use a lot of USB to serial converters and they work really well. Our company has recently started a computer leasing program so we don't have any say as to what we get and none of the new laptops have serial ports. I haven't had any problems with the USB to serial port converters we use and the newer Mitsubishi PLC's can be programmed directly with USB cables. No serial port doesn't seem to be as big an issue as it sounds....