Isakovic

Idea was something like this. Maybe SB80 needs to be in a separate net, I'm not sure, can't test it.

You should filter the value a little bit before displaying it, analog input jumps a little bit up and down, it's normal, I guess if you display it immediately lcd will look blurry. Maybe take a couple of readings in short time and display the average, or update register that shows value every 2-3 seconds. I reckon value doesn't change drastically in time since it's level.

I always touch left rail two times when doing OR for two bits.

Credits to staff at Unitronics who wrote it.

I got this UDFB from support when asking about NTP. Maybe you need to modify it to suit you. It works. It was easier in VisiLogic. UniStream_070_RFC_1305_UDFB.ulpr

Are you using RFC-1305 function for updating time. If it fails in reading network time it will just write 0? Or you accidental write to system registers for time? You said it's a bulky code.

I've seen this once. Connection was breaking because there was a card reader on the network with the same IP address. What does "socket state 34" mean in your picture, I can't find it in help files? If you already tried with keep alive registers, maybe try the next sequence: When SB148 goes down (or some other condition that recognizes Ethernet problem) call socket close block, then delay, than initialize socket to UDP, then delay, then initialize it back to TCP. This resurrects blocked socket in my experience, maybe (probably) there's a more elegant solution. Are there any other client applications besides you accessing via VisiLogic?

"Jazz generation 3" I don't know if Unitronics plans this, but there are applications where having 230V voltage for logic is convenient.

Bundle all bits and registers into couple of consecutive registers with struct command, so you can send them all with one Modbus command. Of course, you have to unpack it on the other side.

That is great.

Usual workaround is to put an MI for user input and mask it to 1 decimal place. Then divide it with 10 in ladder to convert to float.

True. I wasn't paying attention. I can confirm that Modbus functions can be called one after another without delay (with "Modbus in progress" bit as condition) and it works without problems. As soon as one function is called "Modbus in progress" bit is set in the next rung blocking second function from being called before first one is finished. Maybe if you called subroutine with CAN write functions after each of those rungs in the picture you first posted, it could work without timers. Although, I don't know if it would make any difference.

It seems to me that this happened: Rung 6 gets executed because stage index in 3, at the end of the rung index is incremented to 4 so the next rung 7 also gets executed. When you say some messages are ignored, is it that only the last message gets through?

Does anyone know what is the purpose of register SI280? What "minutes" is it counting? I can't find it in help file. I ain't using it, just curious.

No problem Johschr, glad to help. You could see what is stored in MI900 and following registers by opening block "SD Utility Delimited Line". There you will see data that is written. It will be couple of rows of what is to be written into CSV file, each row in this block will be data in consecutive columns. Ex. #1 Indirect text - ML 15 (Because you have a function block that turns date into ascii in line 1 of your code) #2 Indirect text - ML 10 (Because you have a function block that turns time into ascii in line 1 of your code) #2 Numeric field - MI0 (Maybe a process value, pressure) So block "SD Utility Delimited Line" will take all those fields, add delimiters on the end and store all that into one line of ascii characters starting from MI900. That's how to see what is in MI900, basically one row of your CSV file. It could be that MI900 quickly changes value when function is called because it first holds titles of columns until they are written in line, and then gets overwritten with process data. Can't really say what is causing PLC to freeze. Looks like up arrow on keyboard is used to reset status bits from one write function to allow the next one to be called, from what I can see in the pictures. Does data get written into CSV after pressing it? Maybe there is some sort of conflict if you are accessing and SD card while PLC is writing to it. Just guessing now, troubleshooting someone else's work can be difficult.

MI900 is the beginning register of a line that will be written into CSV file by block "Write -> SD". So MI900 and couple of registers after it (MI901, MI902...) will contain ASCII stuff to be written, each register is 16 bits, so it will hold two 8-bit characters, it's difficult to interpret what those registers contain just by looking at them. Help file is useful, open every block and click help to see what it does. How big is that file that you are writing into? Maybe there is a limit to how large it can be. If you are writing every minute it can get big over time.

Can you use other "strange" function codes? I've seen that code 35: works for ML, DW and timer registers.

I don't know why you use Drums, maybe just try rapid fire like in the picture, it could go faster. It works for me, but I always use 9600 though. Good luck.

VisiLogic lets you put coils in series and get the same result as putting them one atop of another, like your step 20. Code gets more compact when you have a lot of coils. Thanks for the feedback, it's good to see results.

Maybe you mean input impedance for 4-20 mA? You see how many ohms your transmitter can supply, and this should be less or equal to sum of all analog inputs impedances through which current signal is running. You should worry about this only if you have more than one analog input on a single 4-20 transmitter.

For Unitronics side you need Modbus config block and scan block in your ladder. And also Modbus address space to find what you want to read, you can find all of this in help files and examples. You can also use system operands for Ethernet (SB, SI and SDW) for troubleshoting, To see if Fatek's messages are getting through.

Laptop I use has strange behaving com ports depending on whether the charger is plugged or not. Grounding issues I guess. Sometimes it takes several tries to get it communicating with the PLC.

I used one V350 that logs CSV file on SD cards and then sends it by email on local network. Maybe this can be one option.

I remember being confused with these terms at the beginning, also with different types of download.