Modbus/TCP to Cognex Insight

[Controls Guy]

Has anyone been able to get a Do-More to act as a client with a Cognex camera?  Care to share the secret handshake?

So far I've been unable to do it.  The only times I've tried were when a Do-More and a camera were present in a project, but so far the project architectures have been such that the Do-More didn't need to do so, so I was only doing it for experimentation/learning purposes.  The MxX box just times out, but I can successfully talk to the same camera with SCADA systems, Windows Modbus utilities, etc., and have done so in the past with DLx PLC's with an ECOM.

Since I've done no Modbus mastering yet with Do-More, I thought I might be missing some step, or maybe there was some issue with Do-More.

Finally had some time to test further today, and set up a Do-More to poll another one. I just checked the config (but didn't need to change anything) for @IntModTCPClient, dropped in an MWX and an MRX, and it works like a champ.

So now I have two devices both of which seem to work fine so long as they're not talking to each other* (except the Do-More hasn't been verified as a client with a wide variety of servers).  I may have to resort to the magic mirroring switch to dissect the request and response frames, if any.  Any better ideas or things to check?  I don't have a camera handy but can probably arrange for one.

You might consider adding Modbus to the items that can be monitored real-time using DMLogger.  It really helps with the things where it can be used.  Also, I'd like to request a shorter poll time option for Memory Views, 1 second or less.

*About the only difference between the working DM-DM setup and talking to the Cognex is that in the DM's, due to the configured Modbus memory size in the server DM, I'm reading and writing to register [4]3000, while the target addresses in the camera are [4]30010 and [4]50000.  That might be significant, I have no idea.

[franji1]

Memory View is optimized to let you monitor/read/write thousands and tens of thousands of data points from a single view.  That is its primary purpose.  It is not meant as a real-time debugging tool (there are other views for that purpose).

Data View is optimized to let you monitor 1-99 data points in a single view VERY FAST (relatively speaking).  Is Data View's polling rate fast enough (50ms/20Hz)?  You can have as many Data Views opened as you need, if 99 is not enough.

Trend View is even faster (20ms/50Hz) and is EXCELLENT for real-time debugging.  It also lets you log data to a .CSV text file to load into Excel and/or a .TRARC Trend Archive file for later analysis within Designer.

[franji1]

What is the IP Address of your camera?  What is the IP Address and Subnet Mask of your Do-more Ethernet port?

[Controls Guy]

Memory View is optimized to let you monitor/read/write thousands and tens of thousands of data points from a single view.  That is its primary purpose.  It is not meant as a real-time debugging tool (there are other views for that purpose).

I was under the impression Memory View was added in response to user requests arising from competitive features?  If so, its purpose would have to be whatever purpose those features are used for in practice, I'd think.

Data View is optimized to let you monitor 1-99 data points in a single view VERY FAST (relatively speaking).  Is Data View's polling rate fast enough (50ms/20Hz)?  You can have as many Data Views opened as you need, if 99 is not enough.

Correct. That's exactly what I want.  Data View, but GOOD, like a Memory view (or you could think of it as a Memory View that's as fast as a Data View for similar numbers of registers, say 100-200 per view).  For example, AB has both tabular memory views and the equivalent of Data View, and I've used the Data View maybe three times in as many decades (not exaggerating).  I've always used the much less efficient Data Views on DL PLC's, but only because I had no choice.  Give me a competitive Memory View, and I'd probably never use Data View again.

[Controls Guy]

What is the IP Address of your camera?  What is the IP Address and Subnet Mask of your Do-more Ethernet port?

Don't recall, but I set up one of the two systems where this was attempted, so I'd imagine they were probably compatible.  I typically use a Class C subnet for a machine network, so the first three octets would match.  The second one was set up by someone else, and I didn't verify it, but I'd imagine it was probably correct.  The machines are no longer available to check or test on, so I'd need to obtain a camera and set it up for testing, to answer specific questions such as that one.

[BobO]

A few thoughts:

There's no magic to Modbus. I'm guessing there is some address confusion somewhere. A Wireshark trace will easily resolve it, and we are happy to help if you can send us a trace where it is working.

Yes, we added memory view in response to customer requests. The performance limitation is related to the large sizes it is capable of, but that doesn't have to apply to smaller blocks. Since we let you specify the size to view, it would be reasonable to believe we can improve the rate for blocks below a particular threshold. We'll look into it. It will never be as fast as Data View however.

Finally...I really don't understand the Data View disrespect. Even with Memory View available, I still use it almost exclusively, because it is fast, easy, and my debug needs are almost always random access. I understand the benefit of Memory View. As an embedded developer I use the embedded development version of both, but even there I use the Data View equivalent 3x more than the dump view.

[franji1]

Give me a competitive Memory View, and I'd probably never use Data View again.

Memory View was not developed to replace the Data View.  Both views have their strengths and weaknesses.

What specific weaknesses are in Data View that we could address (e.g. it updates too fast, so you can't read the numbers when they are also changing fast )?

[ATU]

Doesn't DoMore support EIP? I've always had better performance and less issues using EIP than Modbus with Cognex, at least with the CLX stuff.

[Controls Guy]

Finally...I really don't understand the Data View disrespect. Even with Memory View available, I still use it almost exclusively, because it is fast, easy, and my debug needs are almost always random access. I understand the benefit of Memory View. As an embedded developer I use the embedded development version of both, but even there I use the Data View equivalent 3x more than the dump view.

Like I wrote yesterday, in an environment where I have a fast-updating Memory View equivalent and a Data View equivalent, I've used the data view probably 3-4 hours in 30 years.  I have tens of thousands of hours working on  the various RSLogix flavors, and only 3-4 of those have been spent in a Data View. (This pretty much applies only to RSL5 and 500, as 5000 is for the tag-based CLX, and while their data view is tabular, it's field-and-record tabular, not a 2D table of registers.  They've made some steps to improve this in recent releases, so now arrays of values equivalent to a data file in a PLC-5 ior SLC can be shown in a true tabular view.  BIG step forward!)

So why our such starkly different experiences and preferences?  I can come up with three potential factors:

- We work on different projects that benefit in differing proportion from the two styles of data display

- Different mindset on how to view the data / different priorities on quick vs detailed

- You use BobO mode, where I tend to create a data architecture before and while I write code, so related stuff will have a strong tendency to be contiguous for me.  (Maybe this is the answer for your puzzlement why so many PLC guys seem to care where data is stored like I do, to a greater degree than you do.  I've never had a good guess for that before)

(also look at my following response to franj1, where I talk about some of what I don't like about Data View)

[Controls Guy]

What specific weaknesses are in Data View that we could address (e.g. it updates too fast, so you can't read the numbers when they are also changing fast )?

How do I hate Data View?  Let me count the ways:  It wastes my time, my keystrokes, and my pixels.  I have to manually populate it every time, and it's usually with ranges of contiguous registers anyway, or several such ranges.  Thank God for Ctrl-Enter!  AND you have to tell it you want to be in edit mode vs. just going and typing the new value into the register, and then THAT (edit mode) wastes pixels with a new column that has no reason even to exist.  AND, even though the cursor needs to be on the row in question for a single register write, as soon as you hit <Enter>, the cursor moves to the row you DON'T want to be on, so now you have to reposition the cursor so you can do your single register write.  Who wrote this thing, Mordac the Preventer?  AND it isn't an MDI child window.  In AB, I can stack or cascade all my windows, regardless of function.  Data View knows better, so it won't stack, you have to float or split the app window, neither of which is my first choice.  I can make it fill the whole window by sizing, but then resizing is more work than Ctrl-Tab, and what's the point anyway when it's limited to a single columnar (Field and Record) view?  It's also a little inaccurate to say a Data View can hold 99 values.  With typical resolution, even with descriptions off, I might get 30 on screen, so that's the limit to its usefulness without moving your mouse over there and scrolling (which might take something else you care about off screen anyway).

The proof of the pudding (for the way I work) is that in AB (5/500), where I have something probably 90% equivalent to Memory View, and a virtually exact equivalent of Data View, I ALWAYS use the Memory View, and never the Data View.   With a double click, I can have several hundred consecutive values displayed on screen.  Once a data file is displayed on screen, I can jump to any other simply by entering the file number in the dialog in the lower left.  It doesn't waste space on displaying each and every register address, only the one at the cursor location, which is quite adequate.

[Controls Guy]

Doesn't DoMore support EIP? I've always had better performance and less issues using EIP than Modbus with Cognex, at least with the CLX stuff.

As of v1.4, yes -- and my experience with Insight under EIP vs. Modbus/TCP mirrors yours.

However, there are a number of reasons I'm still working on the Modbus/TCP.  The issue arose under 1.3, before EIP was available, and I'd still like to have both options available.  I've yet to do EIP from a Do-More so that also represents a possible significant investment of time (though I want to do that at some point anyway).  Do-More only supports a subset of EIP (Explicit messaging), and I don't know if that's the flavor used by AB and under which Cognex is so well-behaved.  Finally, I don't have a camera at the moment, so I'm limited to testing aspects of the issue that I can do with only Do-More(s).

[BobO]

I have to manually populate it every time, and it's usually with ranges of contiguous registers anyway, or several such ranges.

Or you could open the stored one from the handy save/load from disk function.

AND you have to tell it you want to be in edit mode...

Or you could set it to always come up with edit mode, with the confirmation prompts turned off.

AND, even though the cursor needs to be on the row in question for a single register write, as soon as you hit <Enter>, the cursor moves to the row you DON'T want to be on, so now you have to reposition the cursor so you can do your single register write. 

Or you could hit Shift-F9 to do an immediate write of the current cell.

In AB, I can stack or cascade all my windows, regardless of function.  Data View knows better, so it won't stack, you have to float or split the app window, neither of which is my first choice. 

I don't know what you mean by stack.

[BobO]

Finally...I really don't understand the Data View disrespect. Even with Memory View available, I still use it almost exclusively, because it is fast, easy, and my debug needs are almost always random access. I understand the benefit of Memory View. As an embedded developer I use the embedded development version of both, but even there I use the Data View equivalent 3x more than the dump view.

Like I wrote yesterday, in an environment where I have a fast-updating Memory View equivalent and a Data View equivalent, I've used the data view probably 3-4 hours in 30 years.  I have tens of thousands of hours working on  the various RSLogix flavors, and only 3-4 of those have been spent in a Data View. (This pretty much applies only to RSL5 and 500, as 5000 is for the tag-based CLX, and while their data view is tabular, it's field-and-record tabular, not a 2D table of registers.  They've made some steps to improve this in recent releases, so now arrays of values equivalent to a data file in a PLC-5 ior SLC can be shown in a true tabular view.  BIG step forward!)

So why our such starkly different experiences and preferences?  I can come up with three potential factors:

- We work on different projects that benefit in differing proportion from the two styles of data display

- Different mindset on how to view the data / different priorities on quick vs detailed

- You use BobO mode, where I tend to create a data architecture before and while I write code, so related stuff will have a strong tendency to be contiguous for me.  (Maybe this is the answer for your puzzlement why so many PLC guys seem to care where data is stored like I do, to a greater degree than you do.  I've never had a good guess for that before)

(also look at my following response to franj1, where I talk about some of what I don't like about Data View)

So this is a "size of two horses butts" issue. You have developed an arbitrary development structure based on the limitations of your hardware, which by rote have become canon, and the tabular memory view fits that methodology. Fair enough.

[franji1]

Here's some helpful hints.  I am not looking to "convert" you - Memory View is KOOL!  But just addressing your concerns...

I have to manually populate it every time

Data Views are serialized to disk 2 different ways, 1. auto-magically with your project's workspace (so you never have to re-enter it) and/or 2. As a separate file (so it could be used in MULTIPLE projects, or to be able to re-load your favorites when needed).

AND you have to tell it you want to be in edit mode

There is a setting in Data View to enable EDIT mode for all new views, so you will ALWAYS be in Edit mode for every new Data View.

even though the cursor needs to be on the row in question for a single register write, as soon as you hit <Enter>, the cursor moves to the row you DON'T want to be on, so now you have to reposition the cursor so you can do your single register write.

This was fixed in 1.4.  As soon as you enter anything valid in the Edit column, the Write Current Edit button is enabled.  You no longer need to hit ENTER then arrow back up.

AND it isn't an MDI child window

Yes, this is by choice.  It would burn up a TON of real estate as an MDI window.  By making it dockable/floatable, you get to utilize the best screen real estate for that specific view (docked to side, on bottom for long strings, floating, grouped, etc.)

It's also a little inaccurate to say a Data View can hold 99 values.

Yes, it does require scrolling (but so does an MDI Ladder View).

The proof of the pudding (for the way I work) is that in AB (5/500), where I have something probably 90% equivalent to Memory View, and a virtually exact equivalent of Data View, I ALWAYS use the Memory View, and never the Data View.

When you program in contiguous memory locations of a single data-block, Memory View is definitely a great tool.

[Controls Guy]

Or you could open the stored one from the handy save/load from disk function.

Not really.  That only helps when the list is one you use over and over, which is rare for me.  That is the strength of a Data View (and the scenario for the very few times I used AB's Data View equivalent -- a recurring task where I need to see the same values each time)

Or you could set it to always come up with edit mode, with the confirmation prompts turned off.

Ah, had forgotten about that.  While it still wastes space, at least it saves one keystroke per DV.  I'll remember to set that (at least until I get a faster MV   )

Or you could hit Shift-F9 to do an immediate write of the current cell.

Good to know!  Didn't know that one.  But again, I think you can make the whole thing go away with a couple minor improvements to Memory View.

I don't know what you mean by stack.

Multiple windows, each maximized within the document area of the app window, like multiple Word docs all at the same level of hierarchy.  Not treated like a toolbar, IOW.  You can Ctrl-Tab to cycle between them.