Jump to content

Simon

MVP 2014
  • Content Count

    536
  • Joined

  • Last visited

  • Days Won

    26

Simon last won the day on January 17

Simon had the most liked content!

Community Reputation

44 Excellent

1 Follower

About Simon

  • Rank
    Moderator

Contact Methods

  • Website URL
    http://www.colterlec.com.au

Profile Information

  • Gender
    Male
  • Interests
    Unitronics Distributor

Recent Profile Visitors

34,335 profile views
  1. Somethine else I do in these types of cases is make very simple test programs. For example you say that certain binary images appear as if both images are bing displayed. Create a very simple program that just has the binary image object and enough logic for you to control the change of state for the linked variable. Anothing point to note, are you doing anything with manual screen jumps or screen refresh/re-load? That can also create some weird effects. For example, a screen jump or screen refresh is linked to a direct contact, when the contact turns on, it tried to refresh the screen every scan.
  2. I've also been reminded (by another member of the forum) of the value of performing a full Initialise and Reset. The general idea here is to wipe everything out in the PLC and re-load a clean project from scratch.
  3. I presume you have been developing this program and downloading changes as you go. I would suggest you download a completely blank project to the PLC, then re-open the project above, do a "Build All" and download the full project again.
  4. I can say that the solution to this ended up being straightforward and not related to iOS or app compatibility issues.
  5. I did quick fiddle with the data in Excel. It looks like an offset of -45 counts and then a linear scaling error of -2.4% over the range of the input. Fluke(ma) Actual Count Expected Count Count Diff. Data without offset Percentage Error 4.000 -45 0 -45 0 6.000 954 1024 -70 -25 -2.44% 8.000 1954 2048 -94 -49 -2.39% 12.000 3953 4096 -143 -98 -2.39% 14.000 4957 5119 -162 -117 -2.29% 16.000 5951 6143 -192 -147 -2.39% 18.000 6951 7167 -216 -171 -2.39% 20.000 7949 8191 -242 -197 -2.41% I would not expect this as normal behaviour. The spec sheet gives accuracy of 0.4%. However, apart from the offset and scaling errors, the data looks quite clean. Usually a bad input won't even perform this well. Were you able to test with the field wiring completely disconnected from the analogue module (that includes the commons as well as the signal lines)? I notice you are a few versions behind on UniLogic, the current version is 1.28.34. I doubt the issue is version related, but I would suggest upgrading at some point. I'd be pushing into a more thorough diagnosis of the hardware and field wiring first. Hope this helps,
  6. In line with the suggestions by Ausman, have you also tried opering the Modbus with just the power meter and UniStream together, no other devices? I haven't really seen any issues with other devices not running the same Modbus standard as Unitronics. One thing I do notice is that different vendors use different notation for the wiring - eg A,B, D+, D- . I have seen different vendors use opposite notation. It's easiest to sort this out with two devices at a time, and sometimes the solution is as simple as swpaping the wires. Also when you get drops, what are the error codes telling you? Are they timeouts (no comms), or is the power meter communicating, but returning an error code? My experience with power meters (Crompton, see below) is that they use 32-bit floating point values, but the Modbus address space works on 16-bit words. Hence only every second Modbus address is valid. Also beware of the +/- 1 offset. Unitronics calls the first register as 0, whilst some slave devices call their first register as 0 and others call it 1. Also if you a trying to read only 1 value, you will need to read two consecutive modbus registers. If the power meter is using 32-bit values, trying to read only a single 16-bit value is likely to generate an error. I end up doing a fair bit of experimentation to find the right combination. Disclosure: My company is a Unitronics distributor and also a distributor of Crompton power meters. I have set up several demos with UniStream to a Crompton meter and got them working on both Modbus RTU and Modbus TCP. I have also assisted customers with setting up many different Modbus devices on Unitronics PLCs. So I could say Crompton meters work fine. However If you can't get 3 other brands to work, then I would be looking at the setup rather than the brand of meter.
  7. One option for WiFi is the Moxa AWK1137 (disclosure - my company is a Moxa distributor, as well as Unitronics). It's not the cheapest device that can do this but is designed for long-term reliability in an industrial environment and is well supported. You say the system already has an unmanaged switch "and thus has not been connected to our network". I'm not sure exactly what you mean by that. The fact that the switch is unmanaged doesn't immediately explain why it can't be connected to the network. I assume you can't connect to the network becuase the existing switch is a cabled switch and you need wireless - is that the case?
  8. I'm not aware of anything built-in. I do it manually, and when it comes up as an issues I advise others to do the same. Do it at least once per day, and ecah time you add a new chunk of functionality, or attempted bug fix.
  9. Hi @Cara Bereck Levy I would agree with the above from @Joe Tauser and @Ausman. The way the ranges are currently expressed in the datasheet are scientifically correct (15 bits : 0.61uA/Bit(0~20mA), 0.49uA/Bit(4~20mA)) , but takes a few steps of logic and caulculation to turn that around to something that is useful for the programmer. It should be expressed in terms that apply directly to the programming, as @Ausman has done. The sign bit is meaningless if the signal is always positive or zero.
  10. When using the high-speed input there is dedicated hardware to peform the pulse counting and frequency calculation. This is independent of scan time. The high-speed counter input is looking only for edges (or change of state) of the input signal. So does not matter if the one pulse per rev is the closed or open state. Just to re-state again, you are registering 190Hz with the sensor in the closed state. Following from the above point, this would suggest the sensor circuit has some noise on it that is being counted. I looked again at your first post, you say "black wire to I0, the blue to 0V and brown to common". I should stop there, brown wire is positive supply and should go to 24V. The fact that you see the LED switch seems to indicate the sensor is powered correctly, but it pays to double check. The other thing you can do is replace the sensor with a piece of wire - that is, put a piece of wire into I0. If you hold the free end onto the 0V terminal or leave it open circuit you should get 0Hz. If you rapidly touch it on and off 0V you should get something like 5-10Hz (do this safely of course, perhaps a mechanical switch could be used that you can flick on and off rapidly). Hope this helps,
  11. I would also suggest interposing relays, I think that is an all-round better option than introducing another programmable device.
  12. I think the clue about the span of values is here: 15 bits : 0.61uA/Bit(0~20mA), 0.49uA/Bit(4~20mA) The uA per bit is different depending on the range. I think that the mention of the sign bit is superfluous (and therefore confusing) as the module only has unipolar inputs. I think experienced Unitronics users are conditioned to expect a 4...20mA analogue range to not use the full span of the digtal word, based on experience with other Unitronics families. But as Flex has commented some Vision modules (mainly outputs) will use the full digital scale regardless of whether they are 0...20mA or 4...20mA.
  13. The other thing you can do to score a few confidence points is to use a PC-based Modbus tool. There are master and slave programs available. One example as follows: https://www.win-tech.com/html/demos.htm You can test: Unitronics PLC master to PC-Simulator Slave PC-Simulator Master to VFD Slave You can also try PC-Master to PC-Slave and even PLC-Master to PLC-Slave (using two COM ports). In each case the goal is to confirm that at least one side of the communication is working OK, by process of elimination. The V570 also has a built-in COM port sniffer, so you can monitor the traffic. It is accessible thorugh the info mode. It will be all HEX data, but at least you will be able to see if the drive is responding or not, as the TX and RX data are displayed separately. The issue may be as simple as just swapping RX and TX wires. The most frustrating thing about debugging comms is the way it can all just sit there not working, and you feel like it's all a dark secret. Use any trick you can to "open up" the system and let it show you where the problem is.
  14. No worries, my pleasure. And yes, local Modbus comms is definitely another complicating factor. It's a bit like the old riddle, I have a fox, a chicken and a bag of wheat, I need to cross the river, but my canoe can only take 2 things at a time...
  15. Note also that you can use an ethernet modem and a serial modem simultaneously on the V350. I have seen applications that do this. The obviously (and only) downside is the need to have 2 modems and 2 SIM cards.
×
×
  • Create New...