kaare_t

MrPLC Member
  • Content count

    2226
  • Joined

  • Last visited

Everything posted by kaare_t

  1. MES push or pull data?

    I always "collect" data from the sub-PLC's like you want to do. That way you have one "master" and one place to keep code. But it can depend: Do you also need to "push" data to the sub-PLC's from the MES-PLC (not just pull, but also push)? At which speed do you need this done (pushing data from sub-PLCs to MES-PLC can be a little bit faster than pulling) So if there is no need for both ways, and if speed is not critical then "obviously" go with your suggestion; collect data from the sub-PLC's. But a little more information would be helpful to pinpoint your exact needs. Bare in mind that the number of "sub-PLC connections" are limited to your license (at least in Europe). You might need to add device-licenses. And as a "killer-blow" for going with "collect": Always think DRY ("Don't repeat yourself") when developing any kind of code. I'm mentioning this because a setup where sub-PLC's send data to the MES-PLC involves the same code in all sub-PLC's (with regards to the comms). If you, now or in the future, find a bug in the code, you'll need to update the code on all sub-PLC's, while if you collect data you have "one" place for the source comms-code; the MES-PLC.
  2. GXWorks2- Difference POU and program settings

    I'm just posting a minor comment on this: It's correct like @Gambit writes that it doesn't matter because they are the same thing. I have absolutely no idea why Mitsu have decided to keep the Program and the Local Label in the Program Setting section like you describe, instead of keeping the POU as POU and Program Setting as Program Setting. It is confusing for many. GW2 is designed like this and I don't know why, but it would probably have been better to just link the programs with a label/headername of some sort instead of actually showing the program parts too under Program Setting. In any way it's a minor "problem", but still it is strange.
  3. Adding New Q68DAV Digital to analog module

    Since it's in the 5th slot you probably already have 5 other modules located in the rack... Just add another module in GW2 under "Intelligend Function Module", select your correct module and click "OK". It's pretty straight forward. If you hit any problems, post some screenshots of what goes wrong.
  4. Inconsistent MES-PLC connection

    @Paolo_911: You said you had the QJ71MES96. I believe that @NeilBDSSA is using the CCPU that is "modified" to a MES module by DeviceWise since he/she is referring to the Workbench. At least the software I used to configure the MES-IT (CCPU) is called "Workbench" while the software I used to configure the QJ71MES96 module is "just" a package from Mitsubishi. They are quite different modules, the QJ71MES96 is a module while the CCPU is basically a CPU with software. Please specify exactly which module you are using... I've attached two pictures, one of each unit. Tje QJ71MES96 has ONE network port, while the CCPU has two network ports. Please specify which one you have.  
  5. Inconsistent MES-PLC connection

    Thanks for the update @Paolo_911. Regarding separating the networks I simply meant that you should (I think) have two physically separated networks: 1 "special" for EthernetIP if you utilize their realtime stream, and 1 "general" network. You should have different cables and different switches and so on. The reason why I believe this is so is that EthernetIP can use multicast messaging between nodes which can cause very high network loads. To explain a bit more: Multicast messages is like yelling in a room, if you have 20 people yelling at the same time, no one can understand what anyone is yelling. Multicast is a node that generates network traffic that ALL ndoes receives (and processes to some extent). But I am NOT an Allen Bradley specialist, I'm only stating my limited experience with EthernetIP in a test network. I'm sure it depends on the configuration of the EthernetIP network/nodes. I'm just saying it can be a possible issue to look into if they share switches.
  6. Serial Modbus Comms

    I just noticed in your previous picture: Change both "Online change" and "Setting change" to "Enable". Regarding memory destination you are correct! But try changing to "Enable" first...
  7. Serial Modbus Comms

    Great! First of all, set "Sumcheck Code = None". You're sure that the slave device is using 8-E-1 bit settings?
  8. Serial Modbus Comms

    Hello and welcome! Did you setup the C24 card with "Predefined Protocol" (under Basic settings)? Default is MELSOFT protocol... Did you write the Predefined Protocol to the C24 module (in Predefined Protocol Support Function tool, select "Online->Write to module")?
  9. BMOV block1 block2 n using labels & arrays

    Hi and sorry for the late reply, got stuck with a job. Yeah, strings and (Mitsubishi) PLC's are not the best of friends... No, it does indeed start at "1" but for some (for me unknown) reason there is some overhead when using strings which causes the string to be "-1". Did you figure out how to do your code, or do you have further questions at the moment?
  10. Sorry for the late reply. SLMP is great, but also check out CCLinkIE-Simple (or what it's called), I think that's built-in to the FX5... I bet it would simplify the setup, but I'm not sure of the specs for the "Simple" version in regards to dataexchange quantity and so on. But it's worth mentioning and checking out. All in all, your topology seems like a good choice I believe. Good luck, and write a post if you have questions.
  11. PLC Mitsubishi High Speed Counting

    Well, if it flows e.g. 1 liter a minute, then you can basically go with any input on the PLC. They can all take 10.5 pulses/sec. You need to provide more (realistic) information if you want a realistic answer.
  12. PLC download problem

    If you're using labels, and make big changes then there might be that the devices "shift" so to speak (if you insert code in between other lines of code, then e.g. T100 shifts to T101 which was previously 'ON' and holds this state in the next transfer). I'm not sure if you are using labels, but they are automatically assigned to actual addresses in the CPU, and when injecting code in between other lines of code, devices can "change place" (if not specified in GVL). Further, when you reset your CPU (by power, or remote reset), all devices are reset (set to zero), and the problem "disappears". Again, I'm not sure what you're using, but if you are using labels this is my guess. Further, I would recommend you to start using "Online Data Exchange" (or what it's called) which injects your new code on-the-fly without the need to recompile the complete code, or to 'STOP' the CPU whilst transferring code. It's a lot faster than to continously download new code, and it doesn't reallocate labels during runtime. Check it out
  13. Main Program of CPU Q-Series memory

    As both @Veganic and @Crossbow writes, you nede to size your CPU correctly (or reprogram your code if possible to use loops and reuse code). Some has mentioned that FB's take up a lot of space, but that is not always correct. FBs can sometimes use less space than not using FBs, it all depends on how you use it and how it is configured, but you need to know some basics about them first. First of all there are FBs and FUNs. FBs are instantiated whilst FUNs are not instantiated. If you have something that doesn't deal with states (e.g. Timers need states) then you can often put them in FUNs. The same goes for FBs without the tick for macrocode. FBs without macrocode are called as subroutines and are great when not dealing with states, however the payload for generating the subroutine sometimes calls for the use of macrocode even if the FB is not dealing with states. Therefore, if it is a large FB and you use it at least 2 times in your code, and it's not dealing with states, then it's probably a good idea to generate it without macrocode. If you use it only one time (you've created the FB as a structured way of programming), then it's almost always space saving to generate it with macrocode. To be clear on some terms: FB: Function block - instantiated FUN: Function - non-instantiated Macrocode: When enabled, the code in the FB will be "inserted"/injected in your main-code inline without any calls. When not enabled, the code in the FB will be put more or less as a subroutine and called in the proper places in the main-code. P.S. SD card will NOT increase the maximum size of your main program. It will NOT be able to handle a larger code than what you already know. You need to read @Wasan's post in more detail as it is well explained there (devices/log-files/backup).
  14. FX3U-ENET-L no connection

    @Veganic is correct. There is no difference at all between FX3U-ENET and FX3U-ENET-P502 except that port number 502 (dec) is opened for free use in the FX3U-ENET-P502 module. I have absolutely no idea why Mitsu have chosen to do it like this, but it's the way it is. Many years ago I know you had to kind of "apply" to be able to get the P502 module but now I think everyone who wants one gets one. All in all; no difference except P502 has the standard Modbus Ethernet port opened. You use standard function blocks and standard software.
  15. FX3U-ENET - Module not found

    Update FX Configurator-EN to version 1.40 (can be found on Mitsubishi's website I believe - you have to register).
  16. BMOV block1 block2 n using labels & arrays

    I see. Labels are good, and a nice way to structure your code (in my personal opinion). The "problem" with indexing labels is that it needs to be an array. So basically, all your stored recipes must be in an array. I've always used labels so I really don't think of it as a problem. See attached pictures for an example. I've defined two global labels that are essential. The "original recipe" (moving data from this), and the "recipeArray" (this is the collection of all your recipes stored - it's an array of strings - a total of 12 strings/recipes). I've also attached a small code that shows how to use it in two different ways - it's a very small example but I hope it shows the principal. Let us know if this works for your. There are other options available. I've used labels since I started writing PLC code, since I'm from Norway we early adopted the IEC development style and we don't like to use addresses directly in the code (for a lot of reasons....). So there's almost always a solution using labels in my opinion.  
  17. BMOV block1 block2 n using labels & arrays

    I'm still a bit in the dark about what you want to accomplish, not sure if I fully understood your problem but here is some pointers to begin with (maybe you already know about these): Is it a challenge because you don't know how to set the index? Is it a challenge because the index is coming from the HMI? Because the index will point to exactly the device you want to. If it helps, you can use a more direct indexing: Assign a value to one of the built-in indexing variables, e.g. Z1 (MOV index Z1). Then use BMOV D300 D425Z1 K5. This will move D300-D304 into (D425 + valueofindex). For example if Z1 = 0, then it will move into D425. If Z1 = 5 it will move into D430 and so on. Regarding assigning devices to an array, if you are using labels (which it seems like you are since you're referring to labelnames), then you define arrays in the label editor. Just select "Array" in DataType and select the number of elements in the array (can also be modified later by just editing the values inside the "()"). If the above is totally off, and not helping you at all, then I have some questions that might help me understand your issue: Are you using labels (names instead of direct addressing)? Are you using Ladder, or Structured Ladder/FBD (just wondering)? Are you using the built-in functions for recipe in the GOT HMI? Do you have any scripts being executed from the GOT HMI to the PLC when selecting recipes (how do you know which recipe is selected in the PLC)?
  18. BMOV block1 block2 n using labels & arrays

    Hi, and welcome! First of all it always helps to know the CPU type (FX/Q/iQF/iQR or similar), and the software used for your code. I've given some pointers below based on a more general approach. I'm not sure I fully understood your data structure, but would it help to use stringmove instead of BMOV ($MOV)? Then you create an array of strings to replace "myList"? You can loop through your 12 recipes and just use for example: Define recipeArray as an array of strings (recipeArray[0..11] Datatype:String(12)) $MOV myString recipeArray[index] This procedure can also be achieved if you absolutely want to use BMOV instead of stringmove. Just use two-dimensional arrays for your "destination": Define recipeArray as a two-dimensional array of words (recipeArray[0..4,0..11] Datatype:INT) BMOV myString recipeArray[0,index] In both examples above you will of course need a FOR-NEXT loop or a similar form of going through all the original recipes, but it looks like you've got that handled already since you're already into indexing your destination array.
  19. Hello. Comments are not normally downloaded to the CPU. All code is compiled, so FB's are normally a logical view of the code. So if you have no correct source code, or backup of source code then you basically have two options: Upload the latest source code from the CPU, and start adding comments to that (FB's and/or structured ladder will be lost) Use the latest available source code from your computer, and modify it the way it was supposed to be
  20. Connecting 2 HMI to 1 FX3 PLC

    OK, my guess is that it's doable but as mentioned I've never done it on GOT's before. The "issue" so to speak is that they do not get their own "channel" each down to the CPU. I remember doing this on Beijer HMI's using a special purpose data transfer protocol for intercommunication between HMI's. This is not a very clean solution since basically all data were transferred to the first HMI, then buffered and sent to the next HMI. Since it's serial, there is no way to open up additional "sockets" so they will never communicate with the CPU at the same time in any way. Also, if GOT #1 breaks down, GOT #2 will have it's comm link broken and stop working. As you might guess, my opinion is that this is not a very good solution. All in all, it's a little bit messy solution. I would guess that GOT's also have this possibility, but I cannot confirm it as I have never tested it. But in any way: Have you considered to add an Ethernet module to the FX3U PLC? That way both HMI's (plus possible other peripheral devices) could connect directly to the CPU and you wouldn't need all the extra fuzz... Alternatively, just add (if available slots) a BD card (RS422 or RS232) for the extra HMI. In both of these cases there will be instant access to data from both HMI's, if one breaks down the other one still function, and the setup and system will be a lot more clean (in my opinion).
  21. Connecting 2 HMI to 1 FX3 PLC

    I've never done this on GOT's before, so I cannot answer if it will work (hopefully someone else will know). However, have you thought about distance? RS232 only goes 15m, so basically you want to have less than 15m between GOT #1 and GOT #2? And again, which FX3 do you have?
  22. Connecting 2 HMI to 1 FX3 PLC

    There's no problem connecting two HMI's to a single PLC, but I have some questions. Which RS232 port are you referring to? The FX3G and FX3U doesn't have built-in RS232 ports, do you have an extension board? And which FX3 do you have specifically?
  23. 3rd Party Q Series Intelligent Device Modules

    Thanks for the update, and don't hesitate to post again if you run into any issues
  24. Using two PWM function

    Did you try, as a test, to set static values in s1/s2 on both PWM? Just as a test to make sure nothing is wrong with min/max limits regarding your variable inputs...
  25. It depends. If your "only" talking about 5 FX systems to start with, this is not a problem at all. One single R system kan utilize 4096 IO alone. It all depends on what you want to do in the R system - as an example; do you want to just collect data from all the FX and trigger alarms based on simple logic then you can go with a "small" R (just simple alarm-codes for each alarm bit in the FX). However, if you want to "control" the whole factory and use the FX more or less as remote IO stations, where the R is executing the complete code then you should consider a CPU with higher capacity. And in any way; if you hit the roof with one CPU, just install another R system in a CCLinkIE Control ring network. If you need to have the "pyramid structure" (one master to rule them all), then install 2 additional R systems (to a total of 3 R systems), where 2 of the R's are collecting data from all the FX systems, and the third R system is collecting data from the 2 R systems. Basically there's really no real limitation.