Red Lion Crimson 3 data block exchange

Ken Roach

Lifetime Supporting Member + Moderator
Join Date
Apr 2002
Location
Seattle, WA
Posts
17,496
I know I can test this myself with PLCs and Wireshark, but I'd like to ask the Community for some insight before I haul out the gear. The actual application is 30x more data than shown in the example screenshots.

I have a Red Lion Data Station Plus application in which I want the DSP to read a block of data via Modbus/TCP from a "Source Controller" and write the values of that block of data to a number of "Destination Controllers", also via Modbus/TCP.

These devices themselves cannot initiate Modbus transactions; they're strictly "servers".

This seems to be exactly what the DSP is excellent at doing, but I haven't implemented this before.

My question is: Do I need to create a "Device to G3" Data Block in order to read the data from the "Source Controller", or will pointing the mapping of all of my "G3 to Device" Data Blocks to the Source Controller and specifying the Modbus Addresses make this work ?

Bonus questions:

1. Will the configuration shown create three Modbus Reads from the Source Controller, or just one ?

2. Does the High Performance DSPZR model of the Data Station Plus have noticeably better performance for this kind of data exchange ?

I'm going to break this into two posts so the pictures will show in-line.

I think this (with the green arrows and no Source block) is correct.

No_Source_Block.png
 
and the I-think-this-is-unnecessary-option

I think that the red "Device to G3" block is unnecessary for this application.

With_Source_Block.jpg
 
I assume that the devices

Destination_Controller_One
Destination_Controller_Two
Destination_Controller_Three

are all different devices, otherwise why would they be separated out? Therefore they will have different "Unit Numbers" or addresses. So this will have to generate three different reads from the source controller.

However all of the protocols on your network there show the as TCP/IP Master. Surely you will need to have three as a slaves.

I agree with you, I don't think the red blocks would be doing anything, and in fact they aren't mapped anywhere so they wouldn't be.
 
To read from the source devices:
TCP/IP master: 3 devices, all Device to G3

If you want the DSP to act as server for something else to poll it:
TCP/IP slave: 1 device with registers from other 3 laid out however you want, G3 to device

If you want the DSP to push registers to another Modbus TCP device:
TCP/IP master: however many devices you're pushing to, laid out accordingly, G3 to device
 
Thanks for the input !

To reiterate:

I want the DSP to read a block of data via Modbus/TCP from a "Source Controller" and write the values of that block of data to several "Destination Controllers", also via Modbus/TCP.

In this example, there is one Source controller. I want the DSP to read a block of data from that controller just once.

In this example, there are three Destination controllers. I want the DSP to take the block of data that was read from the Source and write that same set of values to each of the three Destination controllers.

Ideally, this would take four Modbus/TCP transactions: one Read, and three Writes.

I wasn't sure if having the three mappings to the three Destination controllers would generate three reads from the Source, or if making the red "Device to G3" block would cause the DSP to have that data in memory to be distributed to the Destinations.

I think that only a Wireshark-and-black-coffee session will sort this out for certain.
 
Last edited:
Okay, I get what you're getting at now.

So under block settings for the source controller block you'll see "Update policy". If this is set to automatic, any registers referenced by anywhere else in the program will be polled when referenced. Whether that would do it 3 times or not I don't know. (Edit: I don't know because the Red Lion "intelligently" decides when/what to poll. It may be smart enough to recognize it doesn't need to poll 3x even though it's referenced 3x.)

2 things you can do in my mind:
1. Change update policy to timed or continuous, then source will be polled independently of your writes to others. You could do timed all around if you wanted to.
2. Store source controller regs to an array as an intermediate, reference array with write blocks. Writes will only be performed when values change AFAIK.

As I have told others, Red Lion support is usually very good and fast (response within a day). Someone technical will reply to your query if you ask a technical question like this.
 
Last edited:

Similar Topics

How do you install update on Red Lion Crimson ver 3.1. Do I just need to run the exe file on the host server?
Replies
1
Views
134
Hi, I am trying to increase the size of the user login pop up using a Red Lion CR1000 7” HMI with Crimson 3.1 software. The login pop up is very...
Replies
2
Views
701
Hello, We are currently running a bunch of g310's connected to their SLC5 PLCs through ethernet. I've attempted to upgrade the program from 2.0...
Replies
1
Views
1,152
Hi I have been using Red Lion products for some time, I had a thought over the bank holiday weekend, As you do. It would be nice if whenever a...
Replies
4
Views
1,035
Well, I have yet another question for the great minds on this forum! We have a red lion HMI for one of our machines and every time I hook my...
Replies
11
Views
1,712
Back
Top Bottom