Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Controls Guy on September 07, 2015, 06:30:19 PM
-
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.
-
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.
-
What is the IP Address of your camera? What is the IP Address and Subnet Mask of your Do-more Ethernet port?
-
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.
-
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.
-
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.
-
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 ;D)?
-
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.
-
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)
-
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 ;D)?
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.
-
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).
-
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.
-
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.
-
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.
-
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 ;D)
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.
-
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.
-
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)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
One more note, while I duck the shrapnel.
Nah. Just a friendly pillow fight...West Point style. ;)
-
I use a desktop probably 5% or less of the time when programming.
Boom.
-
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.
-
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.
-
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.
-
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.
Ouch.
-
I am going to jump in also on the Data View vs Memory View issue even though it is a Cognex thread and I haven't actually gotten to USE the Memory View yet.
I personally don't mind Data View so much, but it does take a good bit of time trying to set it up for what I need to look at right now, which is a moving target. I haven't played with 1.4 enough yet to see if the editing of values is better now (it has been a sore point in DS for years due to all the clicks and moves required to actually change the value.)
What I have noticed in Memory View that I would like to see "improved" even more is:
1) The update time does need to be faster at times.
(Sometimes I am looking to find just what is changing while troubleshooting)
2) I want to at least see the nickname and description with a mouse hover or even with
a click or cursor over. In other words, I don't have that good a memory even though I
also tend to like to group my registers. If it is there, I haven't yet found
it. For me it kind of blows the whole idea of letting DMD assign addresses to
nicknames "wherever".
-
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.
I've always tended to the heavy-duty desktop-replacement type laptops, at the cost of weight and to some extent, bulk. Mine is 15.5", 1920x1200, so I'm not skimping except for not having gone to 17" yet, but even at 1920x1200, there's only so much real estate on a machine you can carry in there with you.
My partner's nice machine is 14" 1366x768, and he also uses a 10" Asus with XP! For programming!
-
I haven't played with 1.4 enough yet to see if the editing of values is better now (it has been a sore point in DS for years due to all the clicks and moves required to actually change the value.)
Set the option to enable editing by default and turn off confirmation...never enable or confirm every again. Double clicking the discrete entry button writes the value instantly. Pressing Shift-F9 from the edit field of a non-bit value writes it. Everyone complains, yet no-one seems to use the make-this-work-better features. I use the mouse very little while working with a Data View, and I edit and write values very quickly.
1) The update time does need to be faster at times.
(Sometimes I am looking to find just what is changing while troubleshooting)
We're going to open it up to run as fast as Data View.
2) I want to at least see the nickname and description with a mouse hover or even with
a click or cursor over. In other words, I don't have that good a memory even though I
also tend to like to group my registers. If it is there, I haven't yet found
it. For me it kind of blows the whole idea of letting DMD assign addresses to
nicknames "wherever".
All of this comes back to the discussion of tag-based versus conventional. Do-more allows both.
I like the idea of adding a mini doc-dump hover.
-
Along the same lines...but more biased toward the tag-based side...we are going to add a user specified sort order to the documentation db in Rel 2. We are currently envisioning a two tiered hierarchy, where n doc records can be associated with a group record, and both individual records and groups can be shuffled around or hidden in the doc view. Those folks who are less concerned about where something is in memory can create logical groupings the same way y'all are doing within a particular memory area...but those groups can be heterogeneous data. Of course the two approaches are not mutually exclusive and can easily work well together.
We see a few other other nice things happen with that rework of the doc db...like being able to specify a display format with each element record, or right clicking on the group entry and creating a Data View or Trend view with the contents of the group. Sadly, groups wouldn't project into Memory Views since they are homogeneous memory only, but for the less DV-phobic, it will provide a very quick-and-dirty way to view group data...without having to manually construct a Data View.
And for you Steve...we are already looking at what it will take to add a laptop-friendly full screen mode that will allow every window to show up as an MDI child. Of course we are going to do the reciprocal as well, every MDI will also be able to become a floatable, so I can smear 6 ladder views across my 3 x 22" desktop.
-
Set the option to enable editing by default and turn off confirmation...never enable or confirm every again. Double clicking the discrete entry button writes the value instantly.
Knew about this one and use it.
Pressing Shift-F9 from the edit field of a non-bit value writes it. Everyone complains, yet no-one seems to use the make-this-work-better features. I use the mouse very little while working with a Data View, and I edit and write values very quickly.
Sorry, I guess I fall into that category today! Didn't know about Shift-F9 (though as you note, now that we have MV's I'll probably use DV's a lot less anyway), but I'll try to remember it and start using it.
We're going to open it up to run as fast as Data View.
Thank you! [hat tip] As I've noted before, your MV surpasses AB's in a lot of respects, so better speed is all it needs to make it a great troubleshooting tool. And, in the event I ever do an MV with thousands of registers showing, I'm really not going to object to a 5 or 10 or 20 second update rate.
Oh, one other question/request regarding MV's. AB, like you guys, will allow casts of INT's of various lengths to bits and viewing bit files as INTs (including manual writes). Not sure if this capability is currently in MV's but if not, I'd like to request it for some distant future release. Not a super huge deal.
-
And for you Steve...we are already looking at what it will take to add a laptop-friendly full screen mode that will allow every window to show up as an MDI child. Of course we are going to do the reciprocal as well, every MDI will also be able to become a floatable, so I can smear 6 ladder views across my 3 x 22" desktop.
A million thanks! :) And yeah, more options is [almost] always the best solution, so people can configure to how they work.
-
2) I want to at least see the nickname and description with a mouse hover or even with
a click or cursor over. In other words, I don't have that good a memory even though I
also tend to like to group my registers. If it is there, I haven't yet found
it. For me it kind of blows the whole idea of letting DMD assign addresses to
nicknames "wherever".
Think we already have a couple of possible answers to this. As you move your mouse over a field, it will display the element and nickname in the status bar...and...hitting F9 is going to pull up the Element Browser with the currently selected field, giving you access to the entire doc record.
-
This sounds like it will work for me. My primary need for the Memory View tends more towards offline values access for support and setting values prior to having the system built and powered (since that means I have about 4 hours before others want it out the door ;) ) I don't tend to have huge numbers of registers.
-
so I can smear 6 ladder views across my 3 x 22" desktop.
Only 22"? You're slipping behind the curve Bobo. Earlier this year, I was at a customer site for a few weeks and the only desk available was in the finance department. Some of those people had twin monitors and they had to have been at least 30+ and with sharp detail. Ah man, they could really fly across those spread sheets! :o No wonder the poor guy in maintenance can't get a decent laptop.
-
Hey if we are all going to suck for stuff here, PLEASE make it possible to copy an element instead of the whole rung! Please! please? plee....
-
I believe that's either in the works or already done and will be in v2.0 or maybe even v1.4.2! (I really like that one too)
-
Hey if we are all going to suck for stuff here, PLEASE make it possible to copy an element instead of the whole rung! Please! please? plee....
This one is in 1.4.2, which is due out very soon. Cut/copy/paste individual instructions within a project or between projects.
-
Including drag-n-drop?
-
Only 22"? You're slipping behind the curve Bobo. Earlier this year, I was at a customer site for a few weeks and the only desk available was in the finance department. Some of those people had twin monitors and they had to have been at least 30+ and with sharp detail. Ah man, they could really fly across those spread sheets! :o No wonder the poor guy in maintenance can't get a decent laptop.
But to be fair, the price of some decent laptops for production people is gonna look really big on 60" worth of monitor!
-
so I can smear 6 ladder views across my 3 x 22" desktop.
Only 22"? You're slipping behind the curve Bobo. Earlier this year, I was at a customer site for a few weeks and the only desk available was in the finance department. Some of those people had twin monitors and they had to have been at least 30+ and with sharp detail. Ah man, they could really fly across those spread sheets! :o No wonder the poor guy in maintenance can't get a decent laptop.
Yeah...cause anything bigger doesn't fit 3-wide on my desk.
-
Including drag-n-drop?
Not within existing instructions, but with the new Instruction Toolbox. Drag-n-drop new instructions from the toolbox onto any of your Ladder Views, anywhere you want the contact/coil/box.
-
Ah OK, thanks. Don't really need it with the toolbox, was thinking of dragging already-addressed contacts, coils and so on.
-
Alright, so back on the original topic:
Do-More(s): check!
Mirroring Switch: check!
Wireshark: check!
Cognex camera: local rep promised a loaner, should be here today
While I have those same items all hooked up, I'll see if I can get E/IP working with the camera, since as ATU notes, they are better-behaved on that protocol. I'll post the results, if interesting or informative.
-
I'll see if I can get E/IP working with the camera, since as ATU notes, they are better-behaved on that protocol. I'll post the results, if interesting or informative.
That would be great, then you can tell me how well it does or does not work with the DoMore if I need to do it someday! Buddy ;)
-
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.
You nailed it, Kemosabe!
Do-More operates in [4]xxxx mode, so if you enter a "1", the frame gets 0x0000. Cognex reads have to start from register 30010 (frame: 0x753a), so you have to put 30011 in the MRX. The Cognex was returning "invalid address", but for some reason I didn't see it in the register I was using for exception responses. Maybe getting overwritten by something else. Likewise with the writes. They say "50000" meaning [4]50000, so you have to enter 50001 in the MWX.
Easy-peasy once you're looking at a Wireshark trace, just like you predicted. Another interesting factoid: The newer cameras that are dual processor (5470's and 8450's IIRC) have some issue with Modbus, so it's not supported at the moment. Hopefully they'll get it ironed out, but you guys may have added EIP just in the nick of time, Cognex-wise.
Now onto seeing if I can get E/IP to work!
-
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.
You nailed it, Kemosabe!
Do-More operates in [4]xxxx mode, so if you enter a "1", the frame gets 0x0000. Cognex reads have to start from register 30010 (frame: 0x753a), so you have to put 30011 in the MRX. The Cognex was returning "invalid address", but for some reason I didn't see it in the register I was using for exception responses. Maybe getting overwritten by something else. Likewise with the writes. They say "50000" meaning [4]50000, so you have to enter 50001 in the MWX.
Easy-peasy once you're looking at a Wireshark trace, just like you predicted. Another interesting factoid: The newer cameras that are dual processor (5470's and 8450's IIRC) have some issue with Modbus, so it's not supported at the moment. Hopefully they'll get it ironed out, but you guys may have added EIP just in the nick of time, Cognex-wise.
Now onto seeing if I can get E/IP to work!
Most common Modbus/TCP issue. Everybody has a slightly different way of describing the same thing. Once you understand how a particular device wants to see it, it is always easy.
Not sure about the exception response. We also stuff the exception response into $LastProtoError (DST38) on the rising edge of the error result. If you think there might be an issue, please let me know. We are days from 1.4.2...
-
Most common Modbus/TCP issue. Everybody has a slightly different way of describing the same thing. Once you understand how a particular device wants to see it, it is always easy.
Yup! :)
Not sure about the exception response. We also stuff the exception response into $LastProtoError (DST38) on the rising edge of the error result. If you think there might be an issue, please let me know. We are days from 1.4.2..
No reason to believe there's an issue. I was using a PLC that had a program in it that I didn't want to delete, and too lazy to upload/clear/test/redownload, so I just slammed an MWX and an MRX in at the beginning of the program. Prolly something somewhere else in the program using it.
-
Works good in E/IP too! See attached DM program, Cognex job file (for an IS7402), and the help file for the E/IP Object Model.
-
Glad to hear. We've heard precisely zero about Do-more's EIP prior to this. How was the experience?
-
Not bad at all. I found Cognex's Object Model docs a little ambiguous, like for example, 0x78/1/16 looks like "InspectionResults / STRUCT of" is on the same hierarchical level as the items below it, but I think it's actually an overall description of 78/1/16, because the user values begin at the third register. Should probably indent InspectionID, Reserved, and InspectionResults, so you can see they're subelements.
That was about the worst of it, though, just simple dumb stuff like that. The Do-More end was cake! :) Thanks!
-
The Do-More end was cake!
Sweet!
-
The Do-More end was cake!
And that's the part we like to hear.