Announcement

Collapse
No announcement yet.

DNloader

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts


  • DNloader

    I just down loaded ver 1.c. It will not even communicate to my comm port. I ran DirectSoft32 and it works fine on com 1 to the plc. I went in and checked comm settings 9600 com 1 etc.. I checked settings in DNloader and they are the same 9600 com1 etc.. So why doesnt it work? I am connected to a DL230.


  • #2
    agnone,
    I too am new with the DNLoader program... I would suggest that you look at your parity... I haven't tried it on the 230 (although I will have to..). I just received a message that told me that AD has gotten with the software deve. (Host) and will have a versoin coming out that will not require the CPU to have a "Stop" switch on the CPU:
    "Adding Program/Run switching to Dnloader has been discussed with the Programmer, and it will probably be included in a future version.

    Thank you for your inquiry.

    Joel

    Technical Support Team
    AutomationDirect"

    I hope that it occurs soon...I need this "like yesterday".
    Good luck..
    Sean
    Forgive the mispellings/grammer.... it's been a long day..

    [This message has been edited by sdsmith (edited 05-24-2004).]

    Comment



    • #3
      Thanks smith for your reply, I tried different settings. Actually I cant even get the "Test Comm" to work so I havent connected to a PLC yet or attempted to. I will wait and see if the newer version comes out or even helps.

      Comment



      • #4
        DNLoader does not work with a 230 because it does not support DirectNet protocol in its one comm port. DNLoader only uses DirectNet. If you have a DCM or ECOM in the base, DNLoader can work there, but I don't think the 230 supports those either.
        There are 10 kinds of people in this world, those who know binary, and those who do not.

        Comment



        • #5
          It doesnt work with anything connected, the test com doesnt work, just says communication error with the target. I read the txt file and it says if you cant get the test com to work no use going any further. I just tried to hook up to a 430 just for the heck of it and it still did not work.

          Comment



          • #6
            It will only work with the bottom port on the 430 (aka Port 1, Port 0 is the top port). The top port on the 430, like the 230, only speaks K-Sequence protocol.

            Can you get it working with the bottom port of the 430? Click here to see the 405 User manual and go to page 3-9 and 3-10 to see how the pin outs are layed out.

            [This message has been edited by franji1 (edited 05-25-2004).]
            There are 10 kinds of people in this world, those who know binary, and those who do not.

            Comment



            • #7
              sorry, double posted

              [This message has been edited by franji1 (edited 05-25-2004).]
              There are 10 kinds of people in this world, those who know binary, and those who do not.

              Comment



              • #8
                Thanks for all the replies. It seems too much trouble to use the program when I can just use DirectSoft to communicate. Still doesnt work after reading all the above replies. Nice idea i quess.

                Comment



                • #9
                  I know this is an old topic but I just ran into the same problem as Agnone.
                  I have 2 250-1 CPU's with identical sec comm port settings.
                  Direct Soft can communicate with both of them no problem.
                  DN Loader will only communicate with one of them.
                  Both had K-Sequence checked under setup comm ports.
                  When I checked DirectNet on the bad CPU it was able to communicate with DNLoader.
                  The only difference that I found with the CPU's was that one was version 3.60(K-seq only works) and the other was 4.10 (needed K-Seq and DirectNet to work).
                  Now to really confuse me, when I use DNLoader to write a password protected image file to the ver 4.10 CPU it goes through the process OK until the end where it does not lock the CPU thereby leaving the logic exposed to anyone with DS4 software.
                  No such problem with the ver 3.60.
                  Perhaps I should have just gone home on time!


                  [This message has been edited by Glenn (edited 01-07-2006).]

                  Comment



                  • #10
                    I think the original CPU AND the DNLoader file both need to be password protected. The "end user" only needs to know the DNLoader file password - DNLoader saves the PLC password as part of the file creation then writes it to the "new" CPU when the user enters the DNLoader password. The end user then will have a password protected CPU without them able to gain access to its program.

                    Here's a link to the flow chart for V1.3 DNLoader:
                    http://www.hosteng.com/SW-Products/D...ow%20Chart.pdf

                    It shows that the "source" PLC CPU needs a password, not just the DNLoader file

                    [This message has been edited by franji1 (edited 01-07-2006).]
                    There are 10 kinds of people in this world, those who know binary, and those who do not.

                    Comment



                    • #11
                      The PLC password = .DAT file password.
                      I tried it with another CPU v3.72 and no problem.
                      It's only with v4.10 that the CPU is left unlocked,
                      However if I use DNLdr via ethernet the program loads and locks the CPU on completion as it should.
                      I have more CPU's that I will try and see if the problem is only with v4.10.

                      Comment



                      • #12
                        It sounds like a CPU firmware issue. You may want to create a new thread or call tech support.
                        There are 10 kinds of people in this world, those who know binary, and those who do not.

                        Comment



                        • #13
                          I think this same firmware issue may also exist in the DL06...

                          Comment

                          Working...
                          X