Device Logon Error on EPEC 6505

caleb1
2022-03-25
2022-03-29
  • caleb1 - 2022-03-25

    Hello everyone,

    I've been messing about making a boot drive for the EPEC 6505 which did end up besides not allowing the .app program to be transferred from USB to PLC.

    Yesterday I started getting problems connecting to the 6505. now whenever I try to logon through Codesys I can't. It constantly brings back the user logon prompt again and again without actually letting me logon, to the point that I can't even close the prompt and having to stop Codesys through task manager.

    Is there a way to remove the user from offline or a way to logon without needing to login through the user?

    The current version of Codesys I'm running is v3.5 SP16 patch 2.
    The EPEC 6505 has all the latest firmware updates.

    I've made contact with my provider of the 6505 who's given suggestions for making a boot drive but it would require me to have access to the 6505 to make such a boot drive easier.

    At the moment i'm making the boot drive through windows, using the same folder structure and file structure as seen on the PLC and incorporating it into a .tar.gz file with a .md5 file as suggested by the manuals.

    Any suggestions or solutions are very much appreciated! πŸ˜ƒ

     
  • sgronchi - 2022-03-25

    Could you please detail better what do you want to do?
    Exactly, what do you mean by "boot drive"? The firmware packet, the application packet installable from service OS or the application packet installable by the ApplicationLoader?

    Are you talking about the Codesys credentials to log onto 6505?

    BTW, you'd better use Linux (a VM is enough) to make SW packets for 6505.

     
  • caleb1 - 2022-03-25

    Thank you for your response.

    With "boot drive" I meant a USB that would be used to install the firmware and applications/visualizations made in Codesys in future 6505 Displays. If firmware and applications can't be installed at the same time then there's no issue with using 2 USB's, but the goal is for someone to be able to take the USB and plug it into the 6505 to then be able to install the program.

    Also, I am indeed talking about the Codesys credentials. The Admin user was made by me because I'm still learning about Codesys and wanted to test if it would allow me to do more things, it did not. but now it's causing issues.

    I'm not good with Linux at all, but I am considering learning it, especially for such situations. currently I'm using the Hashcheck shell Extension to make life easier in regards to making .md5 files.

    Because I wanted to work on some other things for a little while I tried uploading the program via ethernet, but this issue is preventing that from being possible.

     

    Last edit: caleb1 2022-03-25
  • sgronchi - 2022-03-25

    Ok. The application can definitely be installed along with the OS if you follow the instructions in "Creating USB Memory for Updating Application (6505)" page of the manual (you obtain a

    user4_*.tar.gz
    

    file along with its checksum).

    To reset to factory conditions (so removing user management), you should update the runtime, placing ONLY

    user_*
    

    and

    user3_*
    

    files in the USB drive, connecting it to the 6505 (that should be disconnected from supply) and then booting with SERV_EN connected to supply. If you also put

    user4_*
    

    (your application), it will be installed in the same batch.

     

    Last edit: sgronchi 2022-03-25
  • caleb1 - 2022-03-25

    Thank you for your reply.

    That is what I have done already. I followed the manual closely to make the packets, and it copies everything over besides the application.app. plus there's the other problem of not being able to log in to the device through ethernet anymore, even though nothing has changed in regards to Codesys from what it was before I was messing around with packages.

    Do I maybe need to reconfigure the ethernet connection of the device since I had reinstalled the runtime packages?

     
  • sgronchi - 2022-03-25

    Well, if you correctly reinstalled the runtime, it comes back to 192.168.0.2.

    Perhaps you actually did not reinstall the runtime correctly (you should start from disconnected supply and connect supply, ignition and SERV_EN together), then insert the USB pen and check the installation log.

    When you reinstall the runtime, the entire partition holding everything other than the OS (so runtime, application, stored data and so on) is erased (obviously you should install only the runtime, user_ and user3_ files, not your application). So there is literally no chance that you cannot find the panel from Codesys IDE other than newtork issues.

     
  • caleb1 - 2022-03-29

    It's fixed now! 😁

    Thank you for you'r help, Sgronchi even though my problem lay elsewhere.

    As it turns out there's a second drive on the 6505 which isn't reformatted when running the rescue drive. This is where the Linux program in the background is running. When making a user in Codesys and uploading that to your PLC, it makes a file in the /root/ of the 6505. This means that this file isn't deleted when running the rescue program.

    you also can't delete it if the program was deleted because you need the program to login and you can't delete the file through Codesys because you can't login.

    It was resolved through gaining /root/ access with admin privileges, through PUTTY and deleting the files, user, group and privilege managing files need to be deleted, if you then restart the 6505 Codesys will recognize them as deleted and you can connect without having to logon.

    If you have problems with this I'd advice making contact with TOPCON who makes the displays, as they found the solution.

     
  • sgronchi - 2022-03-29

    Yes, we know... we sell both Epec and Topcon :-)
    There are 4 (main) partitions on the display, the OS, the Service OS, the Shadow Update and the Application (which includes the runtime).
    Interesting, IIRC on EGScore series the OS partition is normally mounted read only (it's the rootfs_egscore_xxx.tar.gz, for the reference) so that /root is normally not writable.

     

Log in to post a comment.