kaare_t

Haven't tested the encoder function on FX5 yet, but did you setup the parameters with an A/B phasae counter so that X0 and X1 (or two others) are defined as A/B counters? Also, you say that the inverter sets to 1,5Hz, but what does that mean for the encoder (how many kHz does that correspond to)? Since it only counts one way my guess is that you've setup something wrong. Also: I'm pretty sure you shouldn't use both HIOEN and EI at the same time. You setup the high speed function in the parameters.

Do you have the source code (and what kind of software was used to program it in the first place)? Do you know how large the source code is in steps?

Yes I know, and as I wrote: "It's for a Q series CPU but the MC protocol settings are similar". Look at the pictures from GW2 compared to the Cognex manual and you'll see that they are almost the same.

Did you read the manual from Cognex? They support MC protocol directly and if the scanner you have supports MC protocol, then it's plug and play if you follow the steps in the manual. E.g. a quick google search for "cognex 8600 mitsubishi" ended up with: https://www.cognex.com/support/downloads/ns/215/218/232/Integration%20Note%20-%20MC%20Protocol%20Scanner%20Communications%20for%20In-Sight%20-%20English.pdf It's for a Q series CPU but the MC protocol settings are similar.

Not sure about that error, your FBD Function Block should have Macrocode enabled! Use one of the built-in FB timers (10ms or 100ms) to ensure that you get automatically assigned timer variables inside the FB.

As you are quoting yourself, follow the steps...

I actually do have a comment on this one. To start with I'm a Mitsubishi guy just so you know. At least in Europe Mitsubishi has not pulled or replaced any hardware-series of components for the last decades. Some of the other brands have actually had series of equipment fail and replaced them on a large scale. I'm only talking for Europe, so I don't know how it is other places. On the other hand, the problem with Mitsubishi is that they seldom release the "high tech" feature immediately. They're always slow, and can be behind other major brands when looking at the "high tech" feature on everything. Mitsubishi are a very slow-moving organization due to the extensive testing before the products are released on the market. But in general, I would pick whatever suits you just as the others are writing. And when it comes to lifespan all the major brands seem to have a long good lifespan (just as @Mendon Systems are writing). Asking which brand is the best would be the same as asking which candy tastes the best; you'll get different answers from everyone!

Not sure what you mean here... Post a screenshot and we'll see, but of course timers (and everything else) is supported in FBD! P.S. You know you can also write a function block in Simple Ladder right? Just select it instead of "Structured Ladder/FBD" when creating the FB... If you feel that bad about Structured Ladder/FBD then why not go the Simple Ladder route?

No, no, no! Always develop according to DRY ("Don't repeat yourself") as long as you have the possibility for it. If you have a good reason for it, feel free to share it since I'm basically lost right now. The loop would even work if you didn't use labels, you just switch the labels with addresses (and use a 'Z' for the indexing part inside the loop), so that cannot be the reason. What happens if you for some reason need to change a compare statement, or something else (tiny or huge) in your sequence? One mistake when copying/modifying those 100 lines of code and your out. Also you have to redo all lines of code relevant (in your case 100 lines) which is very time-consuming and frustrating. I made a small test, just to prove how little impact 100 loops have in your case (see attached screenshot). 100 loops increases scan-time by 0.2ms to a total of 0.6ms in my almost empty project. I must also emphasize that your repeating code takes just as much time as the looped code!

M8002

Run a test. I think that the complete cycle time (scantime) will be less than 1ms by running just 100 loops in FOR-NEXT. But just do a test, I don't have one where I'm located now, but it's just a tiny piece of code inside the FOR-NEXT loop so my guess is that you won't see any difference in the cycle time (scantime). You can even try to run 1000 loops, or 10000 loops just to see the difference.

Did you ever get to test this, or is the application at a customer not currently available for testing? Please report back even if it works, it helps others with similar issues in the future

I agree, but do you use FOR-NEXT? If not, every cycle depends on one CPU scan (which lets say is 10ms -> 100 scans = 1 second), while FOR-NEXT will loop inside the scan making it much faster (but of course slowing down the rest of the scan). I've got some questions: What CPU do you have (specific Q model)? Is the scan time critical in your application or can you handle some ms more delay each scan caused by the FOR-NEXT loop?

Have you looked into FOR-NEXT loops? Not sure if I understand you correctly, and you're not posting any code examples, but below you can find a trivial example of a FOR-NEXT loop with comments. You can make the FB in Structured Ladder, and then use it in Simple Ladder. That way you can avoid manual hardware addressing since the compiler finds addresses for you. EDIT: Forgot to add a reset of the "activeValues" array, but you get the picture. Just reset the whole array before the loop runs...

Yeah, "Simple Ladder" is not as good that way. You should move to "Structured Ladder"

Mitsubishi does not provide the possibility to access their development tools via cmd/bash and so on.

If you're going to use Python, I would search for an open-source ModbusTCP library/framework. I'm pretty sure you will find some options. Further, just purchase a QJ71MT91 module with built-in ModbusTCP Server and Client protocols. That will most likely be much cheaper than to manually implement the MC Protocol in Python... My guess is that the money spent on one module for the PLC will be cheaper than using a lot of time implementing the MC protocol. GOT uses the proprietary protocol from Mitsubishi so then you would also have to reverse-engineer. Here are the specs for MC Protocol: http://forums.mrplc.com/index.php?/files/file/1086-q_l-melsec-comms-mc-sh080008lpdf/

ArrayLabel[someIntegerVariable] There you have indexing, just place brackets and any integer you have the index value in.

And a very simple google search if you need the spec.....: http://dl.mitsubishielectric.com/dl/fa/document/manual/plc/sh080956eng/sh080956engf.pdf

Yes, that was what I was wondering about. I've used auto/manual and have never had issues, but I guess I used the wrong term ("start/stop" instead of "auto/manual"). Glad you got it sorted out.

Again. As I mentioned in my post the full spec is in the manual. What more do you need?

This can be pretty done pretty easy by using "INCP" and the second pulse and then accumulating until it reaches 60 (1 minute). Then INCP minutes and reset seconds. Do the same for hours/days and so on and you have yourself a small sequence of code to count/calculate operating hours. What PLC are you using, and what software/language are you using?

Sorry, forgot to ask the first time: Why do you want to re-initialize the loop in the first place? Wouldn't normal start/stop, or maybe bypassing them be sufficient?

If I recall that's not possible. But you could convert every SFC into LD in GX IEC and then save the project as .asc or as a normal GX IEC project. But if you've got a big project I guess that will take some time. But again, probably still better than IL...

Hi! What OS are you running? What VSP software did you use (that is not working)? In GX Developer "Transfer Setup", it often helps to select "via MAC/MTA Transparent mode" when tunneling through software/hardware