Jump to content

Pendalar

Members
  • Posts

    14
  • Joined

  • Last visited

Recent Profile Visitors

887 profile views

Pendalar's Achievements

Member

Member (2/4)

0

Reputation

  1. Saw this today while taking a breather after completing our VPN transition: https://www.msn.com/en-us/news/technology/suspected-iranian-cyberattack-on-key-us-infrastructure-probed-by-security-agency/ar-AA1kNaqW?cvid=574519f6e11441188c139bf181aca0e2&ocid=winp2fptaskbarent&ei=103&sc=shoreline
  2. Has there been any official word from Unitronics on this? Still curious if this widespread method is fixable via BIOS update and, if so, ETA.
  3. After giving it some thought and strictly speaking about internet reachability, we would only need the following to likely be secure enough: iOS/Android Remote Operator app connections to the non internet reachable PLCs via passing through a secure connection to an internet reachable work PC that has a static IP (internet and intranet) Would you still recommend a full VPN solution? I'm thinking this could be done with various proxy or tunneling methods but would appreciate some pointers / how to links that should serve the purpose with some light modification. It's possible there is some functionality in the router we used by I don't have access currently to dig around.
  4. @Flex727 I haven't thoroughly read all the various news articles to see if there are any details about how exactly the attack works, but I'm wondering if the exploit necessarily needs brute-forcing the PLC name. If it doesn't, I wouldn't imagine setting it to an extremely long name with only special characters to necessarily help secure it in this case. Obviously couldn't hurt regardless 😥
  5. I'm afraid I can't supply much on the how-this-happened end due to the lack of logs per our IT's router settings and such. I can verify, however, that we had the same PLC names for ~6 years on that particular PLC, fairly standard service ports reachable via the internet, and our PLCs were not behind a VPN. Probably was asking to be hacked I guess with that setup 😅 On the repair end, I updated the PLC name in the programming suite to GAZA after reviewing Info Mode, flashed a current BIOS / full wipe, and then downloaded/burn. Was a quick repair once I understood what was going on. Preventing a reoccurrence however, will be new ground for me / semi-hand tied on the upstream security due to IT policies.
  6. Wasn't certain where to drop this but... woke up to a coworker texting me the attached photo. Luckily they renamed the PLC to "GAZA" and didn't actually do too much damage.
  7. Hi all. I'm looking to purchase a US7-B10-B1 as a test rig initially for learning Unistream (some experience with Visilogic already but want to dive into Unistream). No need for I/O or anything complex at this point. While I have done some programming, I'm extremely new to the hardware side of things so this will be painfully "noobish". That said, on with the mini project... I want (generally) to have the US7-B10-B1 in some sort minimal enclosure (10x8x4 ish?) with only notches for the HMI, power cord, and ethernet. Any thoughts/recommendations would be appreciated in regards to the following: Reasonably priced enclosure manufacture that does the panel cutout to specs? Any power considerations, as far as needing to include other hardware in the enclosure that may or may not alter the general dimensions that I should look for? Anything else I might should consider aside from later migrating the test rig to a production unit with a full scale enclosure, I/O expansion, etc? In the end/restated, I'm looking to protect the unit while being able to view the HMI, and only need to access a power cord and ethernet.
  8. From Joe's explanation, the 4/20 with a 14 bit would round to 3277, but I'm asking if the value in the linear function should be -1 from that (3276)
  9. Thanks for the explanation / makes sense. As you said, probably never notice it in the real world, but then shouldn't the lower bound be 3276.8 - 1 = 3275.8, rounding to 3276 rather than 3277? Asking more for learning purposes than concern over nth level of degree accuracy of the RTD.
  10. My god... I actually understood that. Much thanks! This is how I had it set up when I left today but was unsure of it (aside from using 16383 vs 16384 for whatever reason), maybe just a typo. In my defense, the RTD and transmitter wasn't my choice, I'm' just the one trying to make the PLC like it.
  11. Greetings all. First round setting up a RTD and, after reviewing forum posts here, I believe I am more confused than before... but likely an easy answer for most around here as I'm much more of a software guy. Our setup: V700 Model with an RTD going to a IO-ATC8. I do not have the RTD model# on me at the moment (typing this after hours but can provide tomorrow) but I know that the RTD contains a Prosense XTH-0300F-PT1 transmitter (0-300 degree F even though the RTD itself is capable of a much larger but unneeded range) I understand that the IO-ATC8 is 14bit. The confusion: I've seen forum posts where the linearization block references the "resolution @ 4-20mA" stated by the RTD/transmitter (I cannot locate this on the spec sheet for the model listed above, or maybe it's called something other than "resolution" but means the same thing?). I've also seen where the linearization is based off the 14bit module (3277 - 16383) - which is in line with what we did with level sensors... aaaand I've seen where, in other cases, an RTD does not require additional linearization (other than dividing by 10, but I assume this is for 10bit setups?). Any advice would be appreciated with a layman's outline of rationale. Cheers!
  12. We have one a few of these and my only hurdle with it was power supply related. The instructions imply you can run off USB to PC, USB to power brick, "DC2.0", etc and rated 5-15v, 500mA. We tried all manners of common USB power bricks and it would flake out like crazy. Eventually used a travel adapter to dial it it and now it works perfectly. One would think it would pull in what it needs and be happy but, no, it was very picky to be stable. Since then, we bought a few VAP11G-500 (higher range model) and it requires 5.5-15v, 3A... Now to find an appropriate power supply so they too can be happy.
  13. Greetings all. We have started a minor project at work and we are, admittedly, pretty new to doing any sort of networked communications from PLC to PLC. We have 3x V700 currently and what we hope to accomplish is simply to have (perfect world) a full rendering of the remote HMIs on each of the PLC. Therefore, PLC A would have a link to go to PLC B's HMI and another link to go PLC C's and be able to see the HMI as if standing at that PLC - akin to the iOS remote operator app or using the Windows remote operator software. The question in the end is has this already been easily implemented in some way? Otherwise I assume we would have to use TCP/Modbus or UDP_Raw to pull in valves from PLC B and PLC C but have the HMI of the remote PLC be copied into PLC A's project files. Doing so would make it tedious to keep up with changes to the other PLCs to back implement in the PLC A's code so that the HMI would look correct and all the variables continue to match. If anyone has tried to do a complete remote HMI mirroring / remote op from a secondary PLC, please advise on any tips that might point us in the least painful direction. Cheers!
  14. We used one of these as well but found two issues : a) It didn't seem to get anywhere near the range and ended up buying the next model up for better range and b) To power it after initial setup in the PLC cabinet we tried to use a USB power brick which was very trial and error to get it to work. Initially tried a 1A and then a 2.1A. Neither worked although it should have been fine as long as it was 5-15v per the manual. In the end, we settled on a 6V 0.5A (since 0.5A is what traditional USB supplies anyways) DC adapter - fired up fine. Otherwise have been really happy with this solution.
×
×
  • Create New...