Modbus/TCP to Cognex Insight

[Controls Guy]

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.

Not at all.  It's the more efficient way for me, hardware limitations or no.  Less keystrokes, less time, etc.

[Controls Guy]

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).

You're assuming I mean "every time I want that list of registers".  I don't actually do that.  I mean "every time I open a Data View I have to enter the list of registers I want".

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.

Thank you!

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.)

That's the exact opposite of the actual case.  I'm PREVENTED from using the ideal screen real estate (under the other window, accessible with Ctrl-Tab)  In the MDI model, I have the flexibility to split the screen, but the non-MDI model doesn't let me stack.  I could replicate any of the layouts you describe as optimal with MDI, but can't create the one I like/need with non-MDI.

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

Right, and there's certainly nothing wrong with that.  But in the thick of comparing with Memory view, that 99 number gets thrown around as if it were the data point to compare; I'm just pointing out that it is not, and 25-35 should in fact be used.  In fact, even large MV's need to be scrolled, but at least you get several hundred on screen, so you scroll less and have a better chance of not moving other critical registers off-screen.

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

And it doesn't even have to be a single data block.  In AB, just like with Memory Views, you can open several at once.  I think I had almost 500 values on screen at one time in three AB data file windows.  (Athough theirs are better, since they're MDI so you can tile them exactly without having to approximately stretch them manually)

[BobO]

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.

Not at all.  It's the more efficient way for me, hardware limitations or no.  Less keystrokes, less time, etc.

The arrangement of data into contiguous ranges of homogeneous memory is what makes this a time savings. If you were using strongly typed memory simply as a system allocated resource, rather than arranging in memory the way you do, the memory view would not be as helpful. You choosing to develop that way was predicated on hardware limitations...for example, comm efficiency, homogeneous variable blocks, and minimal data typing. And while you spend less time with the memory view than I do with a data view, you spend more time arranging your world in memory than I do. The development values that were best for the state of the world 10 to 20 years ago pushed a particular methodology that is still efficient for you today. Nothing wrong with that, but it really is a two horses butt thing, because were you starting today, you might end up with a different methodology.

[BobO]

By that "stacking" definition, you can definitely stack Data Views. You cannot hot key between windows in the stack. We could probably add it pretty easily, but I perceive it to be a moot point. You aren't using it, and aren't gonna.

[Controls Guy]

The arrangement of data into contiguous ranges of homogeneous memory is what makes this a time savings.

Agreed.

If you were using strongly typed memory simply as a system allocated resource, rather than arranging in memory the way you do, the memory view would not be as helpful. You choosing to develop that way was predicated on hardware limitations...for example, comm efficiency, homogeneous variable blocks, and minimal data typing.

Somewhat true for comms and so on, but not so much on data typing.  Continuing with the AB comparison, the tabular controllers (PLC's and SLC's) type data files as signed INT, Real, String, and so on, so it's pretty comparable to Do-More with no heap items (except for a limitation of 256/1000 elements per file/block).  Definitely a different model than say a DLx.

And while you spend less time with the memory view than I do with a data view, you spend more time arranging your world in memory than I do. The development values that were best for the state of the world 10 to 20 years ago pushed a particular methodology that is still efficient for you today. Nothing wrong with that, but it really is a two horses butt thing, because were you starting today, you might end up with a different methodology.

You might have a point WRT design methodology, but where it falls down is that it would leave you forced to use Data Views, which (subjectively, I maintain), are a PITA.  IOW, I think a properly done Memory View is so much more efficient than a defined-on-the-fly Data View, that it would drive the programming methodology, rather than the other way around.  Remember, I've have both in AB for 30 years now, so I could have programmed the way you suggest and used Data Views, but I didn't.  I did it my style and used Memory Views.  IOW, I don't think the direction of the causality arrow is as clear as you suggest.

[Controls Guy]

By that "stacking" definition, you can definitely stack Data Views. You cannot hot key between windows in the stack.

But only with each other, not with all the other open windows, unless I'm mistaken.  And that Ctrl-Tab IS a big help.

We could probably add it pretty easily, but I perceive it to be a moot point. You aren't using it, and aren't gonna.

Yeah, but the MDI issue is equally valid WRT Memory Views.

[BobO]

We were just discussing some of this in our weekly project status meeting. The needs of laptop-centric users are greatly different than the needs of desktop users. You view dockable/floatable as a bad thing and want everything in MDI...which ironically is easier to implement...but from my perspective is a horrible limitation. I want to be able to tear them off and scatter them around my 3 x 22" desktop, whereas you want to efficiently manage a single workspace. It's a valid point and we have made added a case for 2.0 to look at how we can be more laptop friendly.

[ATU]

One more note, while I duck the shrapnel. The reason I suggested EIP is that I had a project a few years ago using a 260 and 2 Insite 5000 cameras. Reading and writing about 25 pieces of data with each camera on a molding operation every 12 seconds running 24/7.  After 2-3 days the cameras would lock up. Talked with Cognex tech support and they pretty much told me that it had to be on my side. I worked days on this, used a sniffer and came to the conclusion that I was doing nothing wrong. So I called the main Cognex office and got connected with someone who was one of their software developers.  He told me that the Modbus TCP/IP protocol had a memory leak. He told me that it was a low priority and recommended I could use the EIP protocol. They may have fixed it, but who knows. Thought I might warn you.  Ok, I said my piece, as you were.

[Controls Guy]

We were just discussing some of this in our weekly project status meeting. The needs of laptop-centric users are greatly different than the needs of desktop users. You view dockable/floatable as a bad thing and want everything in MDI...which ironically is easier to implement...but from my perspective is a horrible limitation. I want to be able to tear them off and scatter them around my 3 x 22" desktop, whereas you want to efficiently manage a single workspace. It's a valid point and we have made added a case for 2.0 to look at how we can be more laptop friendly.

That's a VERY interesting observation.  I use a desktop probably 5% or less of the time when programming.  If I have a good-size commissioning project, I might take a 24" LCD to the equipment/site and use it as my laptop display (but even then, as you note, I typically don't use it as a multiple monitor, but rather turn the laptop into a mini-desktop with a single screen).  I'm an old guy, what can I tell ya?

[Controls Guy]

One more note, while I duck the shrapnel. The reason I suggested EIP is that I had a project a few years ago using a 260 and 2 Insite 5000 cameras. Reading and writing about 25 pieces of data with each camera on a molding operation every 12 seconds running 24/7.  After 2-3 days the cameras would lock up. Talked with Cognex tech support and they pretty much told me that it had to be on my side. I worked days on this, used a sniffer and came to the conclusion that I was doing nothing wrong. So I called the main Cognex office and got connected with someone who was one of their software developers.  He told me that the Modbus TCP/IP protocol had a memory leak. He told me that it was a low priority and recommended I could use the EIP protocol. They may have fixed it, but who knows. Thought I might warn you.  Ok, I said my piece, as you were.

I remember you mentioning that experience before, but I think they must have fixed the memory leak.  I know I have a number of Insight applications using Modbus that have run for years with no issues, both with DLx PLCs and other Modbus/TCP clients.

[BobO]

One more note, while I duck the shrapnel.

Nah. Just a friendly pillow fight...West Point style.

[BobO]

I use a desktop probably 5% or less of the time when programming.

Boom.

[Controls Guy]

AND....I don't hate the DV nearly as much when I do work on a desktop.  Still hate the field-and-record layout and having to enter the points (which are usually consecutive anyway), but the screen space thing barely raises its head.

Funny, I never noticed the linkage between those two issues till now.

[BobO]

There are a huge number of second and third tier revelations that have come from our recent epiphany that "we are not our customers". A major one is about ease of use and the prioritizing of mental model intuitiveness over design model simplicity. A second one is that our users use laptops at a higher frequency than we do. We have always considered laptops, but we have never made an effort to optimize the laptop user's experience. We will.

[ATU]

I agree about the laptop screen issue.  Since I got a 17inch laptop screen, its not so bad. However on the factory floor, the techs seem to always be ones with the worst laptops. Most are hand me downs from management with 14 and 15 inch low res screens.