Please tell us what your experience has been with Do-more...

[plcnut]

DMLoggeris very handy, but it really needs some type of text wrap and/or horizontal scroll so I can view the whole string without exporting it. And also it would really be nice to be able to see the headers sent with TCP. While I'm at it... Could I somehow edit the header sent out over TCP?

[BobO]

We're happy to provide the source in either C++ or C#. You can mod it to your heart's content.

As for the header, there isn't one...it's just a standard UDP packet. In truth, the logger device itself is just a builtin UDP connection that hard codes the broadcast address and port 0x7272. You could do the same thing by manually creating one and doing a PACKETOUT. Anything else contained in the packet is put there by the networking stack.

[franji1]

DMLoggeris very handy, but it really needs some type of text wrap and/or horizontal scroll so I can view the whole string without exporting it.

The DmLogger app is resizable, and so the Message column will auto-resize to the full window size.  You can also just maximize it.

And also it would really be nice to be able to see the headers sent with TCP. While I'm at it... Could I somehow edit the header sent out over TCP?

DmLogger is not WireShark, so it is not monitoring Do-more packets.  The Do-more PLC DmLogger device actually sends out UDP "broadcasts" on port 0x7272.  I think what you are wanting is to monitor actual packets to another device???  If so, that's what WireShark is great for.

[plcnut]

I guess I'm showing my lack of understanding here Where does the "200 OK" etc. part of the response header come from?
And again, the Logger is very handy(hope I didn't sound like I was complaining)!

[BobO]

That sounds like part of an EMAIL dump and has nothing to do with logger per se, it's just a part of the transaction with an SMTP server.

[Controls Guy]

Trying to open a TCP connection to stream text to a remote PC, but can't seem to get OPENTCP to connect.  I know the remote server is working because I've connected to it with other clients and streamed to it.  Not sure what to troubleshoot next.  Any ideas?

[BobO]

If all of the critical address/netmask/gateway stuff is correct, I would put Wireshark somewhere it can see the packets going both ways (hub or switch with monitor port) and see who sees what packets. In my experience this stuff works once everything is correct.

[Controls Guy]

Well, in this case the other end of the wire is a Windows PC, so I can just load Wireshark on there.  I'll be able to see if anything is showing up from the PLC or not, but if it is, I'm gonna have to send you guys the trace because I have no idea what a OPENTCP transaction is even supposed to look like when it works.

While I was typing that I wondered if there's a firewall active, but it lets me in from another PC, so I doubt that's it.

[plcnut]

Trying to open a TCP connection to stream text to a remote PC, but can't seem to get OPENTCP to connect.  I know the remote server is working because I've connected to it with other clients and streamed to it.  Not sure what to troubleshoot next.  Any ideas?

I've had this problem... But it was because I forgot to start WAMPServer on my PC

[Controls Guy]

[grins sheepishly]

When I first set up the device that I would stream to, I accidentally configured as TCP Server.  I noticed it and reconfigured as TCP Client.  Designer recognized that the heap item associated with the TCP server would be orphaned and said it was renaming it.  I assumed then that everything was hunky dory, since it seemed to be aware of the issue and fixing it, but there must have still been a name conflict left over.

But, when I created a new device from scratch with a new name, then the bytes do appear in Wireshark on the receiving PC.  For some reason they still are not showing up in the TCP server, but at least I know they made it to the PC, so I'll have to troubleshoot from that point on.

[BobO]

I'm trying to understand exactly what you did...

You created a server object named Fred.
Coded some stuff that referenced Fred.
Went back into the sysconfig and deleted Fred.
Then recreated Fred as a client.

Yes?

[Controls Guy]

Darned if I can figure out what I did.  I can't make it happen again.  What I THOUGHT I did was this:

Created a new TCP server device named Fred

While still in the device creation dialog, noticed that I had made it a server.

Delete and recreate as a TCP Client.

At some point, when exiting the Device Config dialog, I think, I was warned that there was an orphaned heap item which would now be renamed to 'aFred' or something like that.

The recreated device showed as a client, which was the one that wouldn't open.

As soon as I created a new device from scratch with a new name, it immediately was able to connect (sure of this step)

So, for one thing, I don't think there was ever any ladder that addressed Fred while it was configured as a server.

[franji1]

aFred would only be created if an instruction was referencing ANY device called @Fred.  If NO instruction referenced @Fred, then no unassigned nickname device aFred would have been created.

Could it be possible that you had previously created a device called Fred, then LATER went to create a NEW device, also called Fred - cuz we just fixed some bugs for Rel 1.1 that addressed duplicate device names.

[Controls Guy]

I didn't think I had but I can't recreate it now, so I must have, if you say that's the only way it can occur.  I just searched though, and didn't find anything that referenced aFred, but it could have been deleted along the way I guess.

[BobO]

That's why I was digging. I was having a hard time envisioning a scenario that would leave you with a busted device and still be able to download to the controller. If you had stumbled on a hole (you wouldn't be the first...just ask plcnut) I really wanted to know it before we release 1.1...very soon.