Joe Tauser

This is not a trivial task. And yes, the Help is currently a little light on the COM blocks. You'll need to define exactly what data it is in the Mitsubishi you want. Who will be the master - Visilogic or the Mitsubishi? You'll need to get very familiar with this document: FX Communication Protocol It looks like in the Mitsubishi you can set D8120 to turn off the checksum. Look at chapter 6 of the manual. Get a USB->485 converter and develop the strings you'll need using a terminal program- I like this one: Bray's Terminal This is a much easier and faster way to figure out protocol strings. Once you've got the strings you need, you can start to configure your COM:Protocol blocks. Send a request to support@unitronics.com for direct help on this. Joe T.

This one's not as easy as it sounds. Don't do math on the encoder register, do math on a buffer you've copied the encoder value to. What is the actual scaling of the PPR to inches on the belt? Are the items evenly spaced? It may be a simple as counting increments of spaces using the start flag as a shifter / block incrementer and tracking the rejected bits in register. If you have to know the exact location of the item for a the reject station, you'll need to know the distance between the reject station and the "item here" start flag. I'd load a data table and use it as a two-dimensional shift register that is pushed down every time the start flag is triggered. Let the encoder value keep incrementing - if you store it as a long you can snapshot it for a quite a while. More specific info on the application, please. Joe T.

niCAN is hard for a beginner to get their head around. The first thing to remember is that data can only be sent, not requested. The Message Arrived block tells us that someone else sent us data. All data must travel as MI registers. Let's start simply and not try to use the examples. They were written by someone back at the Mothership who has a thorough understanding of the UniCAN concept and protocol and implement register offsetting, which is totally unnecessary at your stage of the game. We're going hard code sending one word in each direction. You also don't have to use register numbers up in the stratosphere, and you don't have to have the lightning speed of reacting to an output that just changed. I've found that a 0.1 second I/O update is fine for getting started. So let's define some simple things for the I/O attached to your RC1: An image of the DI16 will reside in MI 100. It is a 16 bit word and the DI16 is a 16 input module. This is convenient. The bits to be sent to the RO16 will reside in MI 110. Same thing. I like to separate data out a bit, but not too much. This is not true. You can use the Struct to map Outputs to an MI. It's just another memory type. We'll start with sending the outputs, using the non-hardware existent O160..O175. Just because they're not on a module doesn't mean you can't read and write them. In the OUT sub, hang the Struct on the rail and map O160..O175 to MI 110. BTW, the length is 16, not 8. The lower half of your module was feeling neglected. Use a simple timer pulse to send the output image every 0.1 second to V570 MI 110 to MI 110 in the RC1. No need to be confusing here. For the Inputs, the RC1 will send an image of the DI16 to MI 100. Extract the bits encoded in MI 100 and lay them into I160..I175: Do the same thing in the RC1 except reverse the Struct block operation for the inputs and outputs. Um.. the first output is O0 which is O48. So you're almost right. See if the attached programs make it more clear. Joe T. EX-RC1 JT.vlp V570_CANMasterforEX-RC1 JT.vlp

I was unaware they had changed the board shape, but it does make sense because the old Snap I/O modules had a nasty habit of coming un-clipped from the PLC. So to answer your question - yes, they are not compatible. Unless you get your Dremel tool out and cut the corners off. This is worth noting not just for an upgrade but for a replacement as well. I looked at a V570 I had handy and it's got the little plastic bosses that would create the interference you describe. Joe T.

The question of bits being left on and timers not resetting in subroutines comes up often. Think like the PLC. And understand the underlying Zen of a timer or bit instruction. Here's the bottom line - a bit or a timer must be scanned one more time with a Logical FALSE statement in front if it in order to turn it back off. This is true for most PLC brands. The mistake beginners make that they have a hard time wrapping their head around is thinking the PLC still looks at the bits in the subroutine even though it's not being called. If the the subroutine is not being called, everything in it is frozen in the state it was in when you left. Which means bits are left on and timers are not reset. As Flex says, conditional subroutine calls can be bad ju-ju. Joe T.

Have you written the program to define the user's actions already? You'll need something to trigger the data log. By the term "apprentice" - do you have someone you're working with who knows PLCs and is teaching or are you on your own? Joe T.

Try KORE. https://www.korewireless.com/ Joe T.

Have you tried storing a 0 to the ML you have the encoder mapped to? Joe T.

That is one of my favorite clean-up packages. I bought the portable version and run it off the flash drive I keep in my pocket. Joe T.

You're almost there. A normal coil (or inverted coil) ALWAYS updates it's status in the memory table. If the logic leading up to a regular coil is true, the coil will assume a value of 1. If the logic is false, the coil will go to 0. Just like real relays with springs in them. So the regular coils will get in a fight with the inverted coils in the logic you've shown. Never use the same address twice for a normal coil instruction, as it will assume the state it's tied to in the bottom of the program. Remember that PLCs solve logic from top to bottom. Replace the regular coils with SETs and the inverted coils with RESETs. These coil types on only operate on the memory when they're called, not all the time. Joe T.

Contact support for a remote session - go to support.unitronics.com and get a ticket going. We're just volunteer moderators here - not Unitronics employees. Joe T.

The first thing to check is whether you are running the installation program as Administrator. Joe T.

+1 They are confusing and bad ju-ju. Especially for a beginner. @Nancygogogo - delete these inverted coils from your logic and figure out how to make it work with regular coils, SETs, and RESETs. If you're having trouble look over the Help topic "Coils". Joe T.

Don't run a V120 at 115200 - it doesn't work well. Upgrade to a V130 if you need this baud rate. Joe T.

Don't design something you can't service while the machine is on. You'll regret it, or your field techs will hate you. You have to be able to get to the wiring while it's running. If I'm using a standard enclosure the manufacturer usually offers a flying hinged subpanel kit. I order one smaller than the one I'm using and mount it with standoffs. If you have a machine shop you can easily replicate this functionality. Joe T.

Look at the data sheet for the -E3XB and make sure you have +24V and 0V present in the right places. It sounds like you've lost one or the other. Joe T.

If you changed the alarm texts in the String library you can also change the font size there. If you have more questions please post your .vlp file. Joe T.

You need to separate your networks. You have several networks that have multiple rungs, each of which is a logical statement. There's no memory cost for additional nets- move your logic into pieces. You also have rungs that initialize values, such as Main:Net 3 where you write 50 to SI 104. It's better practice to use the power-up value feature for all of this- This applies to SB 168 and SI 108 as well. In net 2, don't put conditions on the SCAN block. Just put a NC of SB 2 on the rail and hang it from that. I would start by talking to one device at a time first and getting that working. Then we can switch between them. We need to solve the Modbus going to 4 and 5. RS485 can be tricky on the older models such as the V230. You may have to play with moving the terminator resistors around or eliminating them. Make sure you have your RS485 polarity right, too. Even though the official Unitronics documentation shows a terminator at both ends, on these old models I have looked at the signal with a scope and found the terminators attenuate the signal too much. Try removing one or both of the terminators while you're trying to get successful communication. Joe T.

Your Modbus block is timing out. Take a look at this post- Also, post your .vlp file rather than trying to describe your problem. It's much easier to look at your code. Joe T.

The M-210 was discontinued long ago. None of the currently available software supports it. Contact support@unitronics.com - they may be able to help. Joe T.

I'm guessing when you say "a PTC sensor with 2 wires" you are talking about a thermistor. The PT100 input is designed for a 100 ohm DIN RTD - 100 ohms at 0 degrees C, 0.385 ohms/deg C. You'd actually have better luck designing a circuit to provide a voltage or current output based on the specifications of your sensor and the temperature range you are interested in. Joe T.

You're going to have to contact the company that made the machine to fix this. Joe T.

Upload your .vlp file. (Post your code) Joe T.

And which online dictionary would that be? Joe T.

Set up a list of texts by range. If you look at my State Machine example you can directly tie the step pointer to the text display. Joe T. @Jeff164 I (and the other codgers) are always happy to look over and help with code you've written. I was anticipating a "Please send me an example step-by-step" response, and that was not fair to you. I apologize for my un-earned gruffness.