GeraldTech

MrPLC Member
  • Content count

    4
  • Joined

  • Last visited

Community Reputation

1 Neutral

About GeraldTech

  • Rank
    Hi, I am New!

Profile Information

  • Gender Male
  • Country United States
  • Interests Science, Automation
  1. Disable BOOTP on built in ethernet port

    Hi All, I actually ended up receiving help from a Mitsubishi Tech support person, who got it to work after multiple attempts. He thinks it was as simple as me having the programming switch in the wrong position. He said it has to be at the program setting (Prog) and not either of the other two. (Rem and Run) I haven't used enough BOOTP to know that myself, but it would make sense that you wouldn't be able to make any kind of networking changes while its running. I think I was using it in "Rem" mode, and I was just switching it back and forth from "remote run" to "remote program" in my laptop. I might look into this further if I get the time. Thanks for all the suggestions, I'm sure someone with the same problem will find this thread useful in the future, regardless of whether this is what actually fixed my issue.  
  2. Disable BOOTP on built in ethernet port

    I've heard a lot of people have BOOTP issues. I actually did try using RSLinx with USB earlier, it failed as well. But good suggestion, the RSLinx software does seem like the best method to use to disable BOOTP (from what I've read) Unfortunately, in my case, RSLinx fails to send the disable command regardless of whether I'm using USB or Ethernet connection.
  3. It's another BOOTP post! I know you're all as excited as I am, so lets get started. But seriously, I'm trying to disable BOOTP on the built in Ethernet ports, not on an Ethernet module. I specifically say disable because BOOTP successfully assigns the IP address to my Compact Logix, however I still need to disable BOOTP to make it a static IP address rather than a dynamic IP address. I'm going to list everything that I have tried, so that anyone with the same issue can have an all-in-one-place reference. (Because there's a number of forum posts and other information for this topic on the internet, with many different suggestions) If I see different ideas/suggestions in other places, I can edit them into this post. Things I have tried: (and you should try if you have this issue) Disabling all firewalls, (For me: Windows/Avast) Disabling all other network adaptors. (Wifi especially, but any and all adaptors you are not using for the setup) Using a different laptop/operating system: (My current laptop runs windows 8.1 and uses a Linksys usb to Ethernet device to talk to the PLC, I tried a laptop running windows 7 which communicated using a built in Ethernet port) Lastly: Try to use all available methods to disable it. For me, that would be: BOOTP standalone server, RSLinx, (Trying to use both USB and Ethernet connections) and finally RSLogix. (Actually, only Ethernet modules have a "disable BOOTP" checkbox built into RSLogix, so that is not an option for me.) [If you have an Ethernet module, go to port configuration in RSLogix and uncheck the "enable BOOTP" checkbox] Anyway, RSLinx Classic (version 3.71) and BOOTP Standalone server (version 2.32) are each coming back with an error when I try to disable BOOTP. I'll attach a .jpg of some screenshots, and some Wireshark save files to show what I mean. In the RSLinx Wireshark file, it shows a "privilege violation" packet being sent from the PLC to the laptop towards the end of the exchange, but I'm not sure what privileges the laptop needs/doesn't have. For the wireshark files: I cleared everything happening before I try to send the command, so that there isn't a ton to search through. As far as timing of the wireshark files go: I start recording traffic, send the disable command (by clicking the disable BOOTP/DHCP button on BOOTP server or "apply" on RSLinx) then I stop recording traffic once I get the error message. So, the captured packets should be just the attempt to disable BOOTP and that's about it. I am sorry that I the pictures are strung together using paint, but I don't have photoshop on my work computer so it's the best I have. Any suggestions/help would be appreciated! (Regardless of whether they are suggestions for me, or suggestions that I may have missed intended for anyone with this problem.) Thank you for your time. Edit: I had the attached pictures open in paint/photo viewer, sorry that they look bad in the forum picture viewer. BOOTP_wireshark.pcapng rs_linx_USB_wireshark.pcapng rs_linx_wireshark.pcapng
  4. Allen Bradley Vs. Mitsubishi

    Akahige is correct on that. I do tech/applications support at a Mitsubishi distributor, and the Mitsubishi support is pretty great, (no support contract either) Also, from what I hear, Mitsubishi hardware is much harder to damage than Allen Bradley. For example, I heard that at least one model of the Kinetix series of A.B. drives have much more fault/failure issues than a comparable Mitsubishi Drive. This could be due to the fact that they don't make all their own stuff. Example: From what I hear, the Kinetix 350 drive was made by Lenze, and A.B. picked it up because the Lenze drive talked Ethernet IP faster or more efficiently than AB drives that were on the market. (We sell Lenze products is how I heard that) And Allen Bradley Encoders are just re-labeled SICK encoders (We sell SICK too) Mitsubishi on the other hand, they don't even release a product until it has been tested for a year or two in Japan. So the products are very hard to break once they reach the US. Just FYI, everything I've written was told to me by customers. (Who have used both AB and Mitsubishi) I typically do programming/Applications, so I only typically only see the Mitsubishi products when they are new, so I can't compare AB and Mitsubishi failure rates that well. (Hence why I rely on stories that customers tell me) Edit: As someone who's currently going through BOOTP issues with an AB PLC, (I wont talk about it here, maybe on the AB forum later) I am very glad that Mitsubishi doesn't use the BOOTP utility. My experience with BOOTP is very hit and miss. I've never had these kind of communication setup issues with Mitsubishi, well, not yet at least. I'm probably a little biased, but I'm trying to take as much of my bias out as possible. Like JRoss said below, since you're an OEM, the best decision could come down to who your customers prefer. (If both AB and Mitsu can do your application equally well)