Jump to content

Manual

Members
  • Posts

    5
  • Joined

  • Last visited

Manual's Achievements

Newbie

Newbie (1/4)

0

Reputation

  1. Yes, for the most part. In our typical setup, the slave drives allow us to configure a custom telegram with all the data we want to read, so it happens in a single read. The one that I am having issues with, the customer wanted custom drives, so we're adapting to use those. Unfortunately, this drive doesn't have a way to setup a custom telegram, so we're reading from their standard locations. Normally I would just read one big block of data and selected what I need PLC side, but this drive limits each response to 64 bytes, so I can't get all the data I need. Any thoughts on the latching MBs? It seems so repetitive and wasteful, not to mention if you need to add more reads like we do in this case, you end up having to shift everything around and add even more MBs. I've been thinking about using an integer and incrementing each time to know which command/response set it's on and it would allow me to skip by incrementing in multiples rather than having all these MBs. For reference, here is what a single drive communication looks like, it takes 3 MBs to track. One for the status read, one for data, and one for the write. Now with this drive, I have to do 2, maybe 3 more reads, so it'll take 6 round trips with 6 MBs to track. Then just have rinse and repeat 7 times. I just feel like there should be a better way?
  2. I've long been doing this for a large program that I maintain. Depending on the system, we communicate with 2-8 slaves. From each slave, we do a read coils, read holding registers, and preset holding registers. The number of slaves is also dynamic, since they could fail or be disconnected for maintenance. This has caused issues in the past since the functions timeout and retry, slowing down the whole loop. To resolve this, we short circuit if the first read operation fails for a slave, we skip the registers. In the end, our solution has basically been to use many latching MBs to round-robin through all the requests. We also short circuit if we know the particular setup will have less than 8 slaves. This ends up having a subroutine that has a bunch of rungs that all resemble each other, check a couple of MB to see if the previous request was successful/failed, run this one, set an MB for success/failure. At the end, we reset all MBs and start from the top. Is there a better way? How do you deal with having slaves that might be temporarily taken out so that it doesn't slow the communication down since it is sequential? It doesn't help that many slaves don't support more than 19200. Is going for MODBUS TCP the ideal solution here? One of the reasons I am seeking alternate solutions is that now we're running into slaves that we have to read from multiple times since the telegram has a size limit, so instead of doing 3 MODBUS functions per slave, we might have 5 or 6, and that just makes for some repetitive and slow loop through all slaves.
  3. I didn't update this thread for a while but thought it would be relevant to post an update. I have long since completed this project. I was able to go back to using MODBUS for the communication. There was no magic bullet other than the RS485 module on the Unistream had failed. It plagued us for a while since it was intermittently working, so we didn't think it was the module itself. After replacing it, MODBUS worked well. We also found that sometimes using a baud rate of 38400 was unstable with certain drives, so we drop it to 19200. On the CANopen/EDS front, I never did find a solution and stopped trying once I was able to get MODBUS going.
  4. Hello, I had actually already reduced the periodic interval to 1 second, but that did not seem to make a difference. I will double-check with those settings. The reason we want to modify TPDO1 is to add some additional data we want to read. That would be things like torque, current, and voltage. Thanks!
  5. Hello everyone, New member, but have lurked around in the past when working with the Vision series controllers. I recently started a project with a Unistream controller. I completed a nearly identical project in the past, but using the Vision controller. I've run into a couple of issues with communication on the Unistream. The first issue I had was MODBUS over RS485. We are using 38.4kbps, 8N1 as the settings. I set this communication up with a Schneider Altivar 61 drive. It was configured exactly like the connection we had with the Vision controller, except now using the Unistream. The main issue we noticed is that it would successfully communicate for 3-5 sessions, but then start just dropping all sessions. The one thing to note is that during development, we use a short run of shielded twisted pair cable with a ground to connect RS485 and add a 120 ohm resistor on the drive end, turn on the termination in the Unistream. Not the ideal connection, but this works on the Vision controller just fine. Could the cable/resistor be the issue, or am I missing something else? I would ideally like to use MODBUS over RS485, as this project will communication with many drives over time. Loading a new EDS based on the drive would require me to modify the program and we'd like to have it be more configurable by an operator. Due to the above issue with MODBUS, we decided to give CANopen a try. We were able to successfully get that communication working. We loaded in an EDS file from Schneider, which at first worked. Once we tried to modify the PDOs at all, Unilogic would not compile. Unitronics helped us out on that end and found that there was an issue parsing the EDS file (there were some extra spaces). Once that was resolved, we ran into another issue. Now, when we try to modify the default addresses on PDO1, we get an EDS initialization error. When we look at the error, it complains that we are trying to set 0x1800/0x01 (the COB-ID) to 0x80000194. I am actually not modifying the COB-ID (leaving it default, which should be 0x00000194, NodeID is 20). I have even tried entering 0x0194 (#H0194) in the EDS configuration, but I still get the same error. Anybody know what I am missing here? I covered a lot of ground up there, with not a lot of detail. I can provide more info, but I am not sure what you guys would need. I am posting some links to the files of the drive in case that helps: Altivar CANopen manual: https://www.schneider-electric.com/en/download/document/1755865/ EDS file: https://www.schneider-electric.com/en/download/document/ATV61_CANopen_V2.1/ Thanks, Manuel
×
×
  • Create New...