MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

112 Excellent


About kaare_t

  • Rank
    Propeller Head

Contact Methods

  • ICQ 0

Profile Information

  • Country Norway

Recent Profile Visitors

5234 profile views
  1. Standardize PLC code for new machines

    Be aware that I personally find this topic a bit "complex" in terms of language so if anything is unclear, or just far off in my post feel free to let me know and I'll try to explain in a different way. I can understand your issue. Regarding the HMI I think that layout designs should be easy to specify when dealing with a machine builder. However, examples of code might be a bit more difficult. The biggest challenge is of course that the developer(s) dealing with the code have their own way of doing their job. I've debugged a lot of applications coded by other developers and all have their own way of thinking. This, of course, makes everything harder to understand and debug. My point here is that the code itself might be hard to specify. Basic circuits can be specified of course (code itself). Logical units of code (like physical I/O, fault handling, HMI code, communication code, machine units and so on) should be separated to files/POU's which in should be structured as specified (by you). Again, the HMI layout should be easy to specify. You should be specific in regards to the logical "unit layout" of the code. Make sure the producer separates code into units and subunits. I highly, highly recommend to make use of labels (even if you don't use names in your main program) just to be able to use functions and function blocks. That way the code can be further segmented into pieces for easier debugging (and more importantly reuse of equal code). Structure in the code together with good documentation will make debugging and/or modification a lot easier, and honestly I think that is what you can expect to get from a supplier.
  2. Standardize PLC code for new machines

    A bit late in the topic, but to jump straight into the  discussion: I'm not sure I understand the "question", or the topic. I have a "double-role" in my work as I am both an employee at a plant (end-user) and at the same time I'm working as a freelance consultant for machine builders and superusers. I would say I have pretty good knowledge of "both sides of the table". I can understand an end-user specifying any given manufacturer of hardware, but if I understand the topic correct you would also specify how the code should be developed? If that's the case, please explain what kind of equipment you are talking about. Are we talking about "off-the-shelf" machines or customized machines? Do you hire consultants to be present on-site for debugging/development of existing plants/machines? Are you getting support for any equipment after the initial purchase? Please elaborate. I'm sorry, it might just be my English (probably my fault since I can there are some other U.S. members that fully understands you), but I would need some more information to be able to give my opinion. If you have the time, please explain more as I find this very interesting!
  3. Communication Socket_TCP

    You'll have to monitor what happens in your code. Where does it fail (which condition is not set TRUE to activate the "OPEN" sequence)? You'll probably need to do this while you have the card/system on your desk, it's hard for us to test this without a functioning system. One advice though is to look if the last sequence (close) "overrides" the first sequence (open). Maybe you have a bit that is automatically reset when you sequence from the first to the last? What you can do is to add temporary bits/words only for testing purposes that shows the actual value of a given variable at a specific point in your code. One example is: IF(M16=TRUE) THEN M20:=TRUE; END_IF; IF(M17=TRUE) THEN M20:=FALSE; END_IF; In this case, if both M16 and M17 are TRUE, M20 will always be false since the last sequence resets it anyway. To "check" for this, you can add a variable for testing purposes: IF(M16=TRUE) THEN M20:=TRUE; testVar:=M20; END_IF; IF(M17=TRUE) THEN M20:=FALSE; END_IF; In this case, you will always know the status of M20 in the third line of the code (after the SET instruction, but before the RST instruction). You can do this as many places as you want. The point is that because of the sequence scan of the PLC, sometimes it might be difficult to see what status a bit/word actually has without using test variables (which you later remove). In event-driven programming there are breakpoints for this kind testing, but in scan-driven programming it's a bit harder... If you're "lazy" you can start by just shifting places between open and close sequences (so that the close sequence comes before the open sequence). Maybe it will only open and never close?
  4. FX-EEPROM-16 problem

    @pv550: First of all, you should start a new topic (this topic is from 2015) when having new questions. Second, to your actual question: You just mount the EEPROM into the PLC, and download. As long as the EEPROM is mounted the unit will boot from it. If you move the EEPROM to a different PLC the "new" PLC will boot from EEPROM. FX-series EEPROMs are quite easy: If they are mounted, everything will transfer to/from the EEPROM. If they are not mounted, everything will transfer to/from the built-in memory.
  5. decimal after point for FN2n PLC

    Don't double post (see #4 in this post): http://forums.mrplc.com/index.php?/topic/33669-c252-counter/#comment-157860
  6. C252 counter

    Convert the original value to float (e.g. FLT D0 D2). Then divide by 100 (e.g. DEDIV D2 K100 D4), then you'll have a floating point number in D4/D5 with a value of abc.xy. So if the original value is 12345, the "new" value will be 123.45
  7. String to Decimal

    I'm not sure if you're asking for conversion into decimal, or integer? You have some instructions for converting from string to "many" other formats and they all start with "STRING_TO_***". So if you want to convert into integer: STRING_TO_INT, if you want to convert into decimal/real: STRING_TO_REAL. BUT: Remember that a 'null' or non-value string will cause an error in the PLC (invalid operation). So make sure you have a valid string input. This means that the first thing you must check is that there's actually a value in the string (if there is no value at all, then just move '0' into the string).
  8. E700 Drive

    Also, in order to do anything like this you'll need a control system. The inverters won't forward->reverse->forward by themselves. You'll need a sequence program. Like @Luke.S writes, it's hard to say if this will work with this little information, you should write more about your application...
  9. GT Designer3 Script Problem

    No problem. I'm really not sure how to do this, it should be possible but I've never tried it before... Did you solve it?
  10. GX works 3 RS2 function

    I thought that you had the complete string already like you describe above (you say that you can already send 43.21)... How do you get this string today? Please write where you get the 43.21 from, and also where "12" and "34" comes from. Are you making this yourself? Are you getting them from a different system? What are they in the first place (INTs, STRINGs....)?
  11. GX works 3 RS2 function

    The problem is the encoding/decoding of words/bytes. I don't know how the string is generated but you need to encode it differently before sending it to the terminal. You need to swap the bytes/words. You need to do e.g. MOV to move around the words and then SWAP to do a rotation of the bytes. I would have a small area of variables for encoding purposes since you will need to shift around a little bit. I have just used some variables as an example below. This is not a complete code, just an example of how it can be solved, and is probably lacking some code also. But it gives you an idea of how to solve your issue. Note the MOV, DMOV and SWAP instructions. First, take your raw data of minute/second H31323334 (e.g. in D300-D301): MOV D300 D310 //I assume that the raw mm is in D300, and then move it to a temporary area (D310) MOV D301 D311 //I assume that the raw ss is in D301, and then move it to a temporary area (D311) SWAP D310 //Swaps the two bytes SWAP D311 //Swaps the two bytes ... Insert your dot (H2e) where needed, then append STX/ETX. At last: DMOV D310 D400 //Moves the complete string into D400 which is the 'send' area
  12. FX-64MR

    Could you take a screenshot (or a photo of the screen) of the error message that you get?
  13. Mitsubishi Safety PLC

    As far as I know, SIL levels apply to the "System Solution", and NOT components. In other words there are no components that comply to any SIL level. The complete solution is evaluated concerning a specific SIL level. But that's just my little knowledge of this. So to write that your 'sensors' are SIL compliant is actually not correct!? I would recommend you to contact Mitsubishi/your rep. directly to get certificates for the safety PLC. If you want to develop code, and this is a critical application you are also supposed to get the code evaluated and approved by the correct authorities. Alternatively you should contact your local authorities and ask for IEC compliance according to the documents that Mitsubishi provides to check if there are any mismatches... There are also different laws/authorities in different countries/regions, so it's hard for us to actually know the answer to your questions.
  14. Verifying a strings nature?

    No problem if there are more than one "out-of-range" return codes, you can just go through several codes and discard message if any match. To continue a bit on this, I always compare the return result binary (compare the hexadecimal representation of the string), before doing any conversion just to avoid the situation you are in right now. If the binaries match a non-string value, then just jump across or disable the conversion function(s). Let us know the progress in your case, nice for others to know in the future. I agree in programming out errors, and just FYI I always program out errors (not good letting a red 'ERR' light on the CPU when when leaving the customer  ). However I have found that during both development and startup/FAT it's a relatively big job to reset the CPU every time there's a small or large bug... Most often, customers also accept the "Continue" option since the machine operation should stop "normally" instead of the CPU actually going into STOP. In other words, when needed, I develop code that checks for error registers and gracefully stop the machine/plant instead of the CPU actually halts everything immediately. But if graceful stops are not "needed" then it's easier to just let it shut off. Let us know if you have any other questions!
  15. Verifying a strings nature?

    You haven't specified the error you get in the PLC, but my guess is an operation error on the DDABIN instruction. First of all, you can make the CPU continue to run even if an operation error occurs. I always select to continue to run unless a customer is very specific (there's no need for the PLC to actually make a stop), the error LED on the CPU will light up red, but it will continue to run. See screenshot of settings. I select "Continue" on all choices. Second, if you want to actually solve the problem I would first ask the supplier what specifically the scale sends in the string when there is an out-of-scale "value". Then do a compare on the raw format of the string and discard the complete string if it matches the "out-of-scale". This way the DDABIN will never run in case of "out-of-scale". Do you know if there's a fixed "out-of-scale" string, or can that also change?