DNLoader Communication Errors

[RStoughton]

I am running Windows Vista 64-bit, and have found that if I pull the second 2Gb RAM card out of my computer (leaving 2Gb) I can connect to my DL05 and DL06 PLCs using the GoldX USB-Serial adaptor and DirectSOFT 32. However, when I try to connect to the same PLCs using DNLoader I get the error "Error communicating to target device". I have tried everything I can think of including switching serial ports with no success. Do you have any work-arounds?

[SteveAbx]

I have the same problem.
DirectSoft 5 works fine with a serial connection to a DL06 PLC, but I can't get DNLoader to connect.
I always get a "Error communicating with target device"
DirectSoft is set up for K-Sequence, COM1, 9600, Odd, 8, 1, None.
DNLoader is setup for COM1, 9600, Odd, 1.

Does anyone have a way to make DNLoader work?

[Greg]

The "DN" in "DNLoader" means DirectNET protocol. Try to connect using DirectSOFT using DirectNET protocol instead of K-seq and let us know what happens. It should work exactly the same.

[SteveAbx]

Thanks Greg.
I have created a Link in DirectSoft5 with the following options: DL06, COM1, 9600, Odd, 8, 1, None, K Sequence, 1, 800, 20000, 1
It works fine, connects, programs, etc.

In DNLoader I have the following options: Serial, COM1, 9600, Odd, 1
If I Test Comm or Read PLC I get "Error communicating with selected device!".

I am trying to use the same serial port and cable into the same PLC for both applications.

What can I try?

[franji1]

K Sequence - It works fine, connects, programs, etc.
What can I try?

DNLoader uses DirectNET protocol, not K-Sequence.  Try setting up a DirectNET link and let us know what you find out.

[SteveAbx]

OK I have another PLC assembled so:

I have created a Link in DirectSoft5 with the following options: DL06, COM1, 9600, Odd, 8, 1, None, DirectNet, 1, Hex, 800, 20000, 1
It works fine, connects, programs, etc.

In DNLoader I have the following options: Serial, COM1, 9600, Odd, 1
If I Test Comm or Read PLC I get "Error communicating with selected device!".

Same effect as using K-Sequence.  DirectSoft5 works, DNLoader doesn't.
BTW I am trying to use the same serial port and cable into the same PLC for both applications.

Any suggestions?

[Greg]

Well, something has to be different. It could be a bug in DNLoader, but before we go there, I'll ask the dumb question:

Are you using the same PC in both instances?

Oh, and also, what Windows OS?

[SteveAbx]

I am not on site with the system now, but it is a single laptop with is Vista Home.
It is connected to the PLC via a USB serial port into the programming lead.

[BobO]

Um...silly question perhaps...

Are you running both apps at the same time? If DirectSoft has the port locked, DNLoaded won't be able to access it...

[SteveAbx]

No.
You have to close the connection in DirectSoft5 to make it release the serial port.
But even after closing each application and rebooting between tests, I still get the same thing.
DirectSoft5 can connect with K-Sequence or DirectNet.  DNLoader cannot connect.

[SteveAbx]

I ran some communications tests today.
DNLoader sends out the following hex codes during a comms test:
4E 42 05 4E 21 05 4E 21 05
It is sent in three groups of three chars.
DirectSoft sends out these chars as it tests the comms link:
4B 21 05 4B 21 05 4E 21 05 4E 21 05
Again as groups of three chars.
In both cases there is no PLC so no reply reactions.

When I connect the PLC, the DNLoader output is unchanged even though the PLC replies.
The DNLoader output is:
4E 42 05 4E 21 05 4E 21 05
The PLC reply is:
4E 21 06 4E 21 06 04 


The DirectSoft output is different as the PLC reacts to the first 4B 21 05 sequence.
This is the DirectSoft output:
4B 21 05 01 50 01 00 00 01 00 17 50 06 04 4B 21 05 01 50 01 0F 00 01 00
17 5F 06 04 4E 21 05 01 30 31 30 36 30 30 30 30 30 30 30 32 30 30 17 05
06 04 4E 21 05 01 30 31 30 36 30 30 30 46 30 30 30 31 30 30 17 70 06 04
This is the PLC input (to the PC):
4B 21 06 06 02 02 00 D0 00 03 D2 04 4B 21 06 06 02 02 00 D0 41 03 93 04
4E 21 06 06 02 00 00 03 00 04 4E 21 06 06 02 41 03 41 04

I don't have a protocol analyser here but I think it decodes like this:
PC   4B 21 05
PLC   4B 21 06
PC   01 50 01 00 00 01 00 17 50
PLC   06 02 02 00 D0 00 03 D2
PC   06
PLC   04
PC   04

PC   4B 21 05
PLC   4B 21 06
PC   01 50 01 0F 00 01 00 17 5F
PLC   06 02 02 00 D0 41 03 93
PC   06
PLC   04
PC   04

PC   4E 21 05
PLC   4E 21 06
PC   01 30 31 30 36 30 30 30 30 30 30 30 32 30 30 17 05 (read 2 byte)
PLC   06 02 00 00 03 00 (reply)
PC   06
PLC   04
PC   04

PC   4E 21 05
PLC   4E 21 06
PC   01 30 31 30 36 30 30 30 46 30 30 30 31 30 30 17 70 (read 1 byte)
PLC   06 02 41 03 41 (reply)
PC   06
PLC   04
PC   04

That doesn't match my DeviceNET spec.
Why do I get some 4Bs instead of 4Es?
What does DirectSoft do when it starts a comms link?

[BobO]

Different protocols. DNLoader only uses DirectNet (hence the DN), whereas DirectSoft can use DirectNet (NSequence) or KSequence. The 0x4E is the letter 'N', whereas the 0x4B is the letter 'K', which is the first character of the enquiry command in the respective protocols.

In the DNLoader example, DNLoader is not seeing the response...have no clue as to why...because the PLC is clearly responding.

As DirectSoft cranks up, it reads a bunch of stuff. Your parsing of the data is correct, and looks completely normal. If DNLoader was seeing the responses, the sequences would look similar.

[SteveAbx]

Thanks Bob.
Is there any other way to program a DL06, without allowing the operator access to the program?
I want to be able to field upgrade the DL06, without having to send a copy of the PLC program that can be edited or modified.

[b_carlton]

I take it that what you are seeing is a strange occurrence. I think the DNLoader should behave exactly as you expected, but it isn't. I'm sure that the hosts of the site (since, I believe, they wrote DNLoader) will be very interested in your experience and will work hard to set it right.

[Greg]

That is true, b_carlton, and I know BobO can speak for himself, but I would only point out that DNLoader is free and we are currently working hard on new products that can keep us all working indoors.  So the issue is not wanting to fix the issue (however, we can't duplicate it here; ours works, and this is the first I've heard of such an error), the issue is merely priority at the moment. All software engineers are currently max'd out, so, unfortunately this means DNLoader has very low priority. Sorry.

I have no record in our database of "Error connecting to target device".

I do have one similar called "Error communicating with target device," but that one was fixed by the customer matching the COM port settings of a DirectSOFT link to DNLoader; something SteveAbx has already done.

So, this is a mystery at the moment, and since we can't duplicate it, it's hard to fix even if we had plenty of time to do it.

SteveAbx, have you tried a different PC? Also, the serial sniffer you are using, was it running on the same PC as DNLoader and DirectSOFT? Or was it a different PC altogether?