Jump to content

Jenkins

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Jenkins

  • Rank
    Member
  • Birthday 09/27/1979
  1. Thank you! I used the settings you both suggested and it is working consistently. Jenkins
  2. Hello all, I have an application with only a few screens. I am using TightVNC Viewer per Tech Support. I have a UDP Socket configured for Port 555 in the UniLogic project and am not using any security for the VNC configuration. I am connecting to the IP Address of the Panel which is different from the Panel. The ethernet cable is connect directly from the computer I am working on. Am I missing something? Are there setting that need to be configured yet? I have attached screenshots of my VNC settings and the message when it closes, Any help is much appreciated! Jenkins
  3. Yes the Red Lion support PCOM http://www.redlion.net/Support/Downloads/CablesandDrivers/G3/Unitronics.html
  4. Redlion offers the Data Station Plus Protocol Converter. It has drivers for BACnet and believe it or not Unitronics. It is a really cost effective solution and can do multiple conversions. It has Ethernet, Serial, and USB on the base unit plus an expansion slot for Canbus, DeviceNet, Profibus, GSM/GPRS Modem, and additional Ethernet or serial comms. The software is free. Here is the link to the hardware Data Station Plus Here is a link to all the drivers Drivers Jenkins
  5. I have recently run into a issue where using the ladder based Autotune for a burner. At the end of a 3 stage tune, we were still getting to big an oscillation. I read on the forum here the suggestion of PID server. So we went to use it. Here is my question. All the values that PID Server is looking for, come right out to the legacy PID Config FB. PID Server needs to have an operand in each of the functions but which are necessary? During the autotune, the Reset Intregal Bit was high but in our ladder we did not include it. For PID Server to work correctly do I need to make sure this is in the ladder? Are there any other functions that are recommended? We did try the autotune without putting the addtional functions in the ladder just linked them to unused operands and still got bigger oscillation then we wanted. The biggest problem was it took 15 min to get to setpoint when the burner is capable of reaching it in 30sec. Any input would be helpful. Jenkins
  6. Here, Here! A community gallery of HMI objects would be great! I also love the idea of a separate thread just for HMI objects and tutorials. Jenkins
  7. Hmmm I will attach a new zip file. Hope that works. Jenkins VMX_mb_reg_map_07292009_release.zip
  8. Damian, THANKS! We have successful communication! I really appreciate you helping me. I will admit, I feel a little foolish for missing that but am happy to report it works with the Mitsubishi. On a side note, I have talked to my customer on that soft starter I mentioned in earlier posts and we can't get that to work. He is going to put his sniffer back on and "fake" some example messages as they are still not communicating. We don't have an offset issue there, thankfully. I will also post any update from that project as well. In case anyone is interested, I am attaching the modbus documentation for the Motortronics VMX Modbus instructions. Thanks again! Jenkins (needs to improve reading skills) VMX_mb_reg_map_07292009_release.zip
  9. AHHHHHH! This is what I get for doing this at work when I am slammed and half the office is out. Damian, I made a typo. It is suppose to be address 9C49 hex, which is 40009 dec. In the Mitsubishi manual, that is the register for "Inverter status/control input instruction". Apparently you read and write to that register. Sorry for the typo. J3nkins
  10. Damian, Thanks for the response. Reading those forum posts were very enlightening. Here is some history on my end. On the soft starter I listed above, there was a RS485 Modbus network with 20 Yaskawa VFDs and 1 VMX Soft starter. The VMX was in the middle of the daisy chain and was not communicating but all of the other devices were. In contacting that company and explaining our situation. They came to the conclusion that it was the CRC byte order. I was not present but had a trusted associate actually attempt to connect to the Mitsubishi VFD. Over the phone, we troubleshot the cable, parameters, terminal resistance, addressing, ladder logic, baud rate, parity, stop bits, etc. We made a test program, with only the modbus in it with one present single holding register command. Still no response. I wrote down that string that was being sent via INFO mode. It was 65 06 9349 0000 7E68. I saw how the CRC was being sent "7E68". I then went to this website here. The bytes were swapped "687E". I made the conclusion that the byte order is reversed. If you have ever programmed an Automation Direct C-More HMI, when setting up the driver for Modbus you have options to change byte order. Maybe they have found something or decided to appease people. I don't know. I have an appointment with our customer with the Mitsubishi VFD and I will hopefully come back pleasantly surprised. Either way I will definitely post back what I find. Thanks again for you responses. JENKINS
  11. Hello Ash, From what I have read in document PI-MBUS-300, it is the opposite where the data is high byte, low byte and the CRC is low byte, high byte. The brand VFD I am talking about is a Mitsubishi FR-D700. Below is their message structure. Another product that adheres to this structure, that I have found, is Motortronics VMX Soft Starter. This is taken from their Modbus documentation. On the flipside is Yaskawa. I have used these VFDs with great success using Modbus and they structure their message the same as Unitronics (high byte, low byte on data & CRC) We could easily use many more products with built in Modbus FB's by adding an option for changing byte order on CRC and maybe even on the data if some manufacturer decides to go off the standard. Thanks for listening! Jenkins
  12. To whom it may concern: I would like to the ability to change the byte order in the CRC of the Modbus Config FB. My reason for this is primarily by use of modbus and VFDs. It seems that depending on manufacturer, the byte order could be LSB, MSB or MSB, LSB. If we had the ability to change this with a simple setting it would replace "work around" code using the Protocol FB. Just a suggestion. Jenkins:huh:
  13. Hello all, When looking at the string generated by the Modbus FB is this: [] = byte [address] [Function] [Registor High] [Register-Low] [Length-High] [Length-Low] [CRC-High] [CRC-Low] According to PI-MBUS-300.pdf, the CRC should be LB, HB. (See Attached Screenshot) My post is two fold: 1. Does anyone have an example where the worked around this? The slave device is looking for CRC LB,HB. 2. A suggestion is to add a pull down in the Modbus configuration to change the CRC-16 order. Jenkins
×
×
  • Create New...