Jump to content


MVP 2014
  • Content Count

  • Joined

  • Last visited

  • Days Won


Simon last won the day on February 20

Simon had the most liked content!

Community Reputation

46 Excellent


About Simon

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Interests
    Unitronics Distributor

Recent Profile Visitors

34,579 profile views
  1. Hi Mat, UnCmDrv1.dll uses the PCOM protocol, same as Visilogic and other Vision apps. So yes you can select the remote TCP port number separately in each connection request, sam as you can do with the standard Unitronics applications. The download package for UnCmDrv1.dll includes some examples, the only one I can open is the Excel VBA example, which is set for serial port. However using the object browser, the port setting object is as follows:
  2. Hi Mat, With the V430 and V350, the port config details in the docs are the default config. If you initialise the ethernet card without overriding these, the 4 ports are initialised to these settings. You can override those defaults using the SOCKET_INIT block in the ladder, one SOCKET_INIT block per socket. This will allow you to set the consecutive port numbers as per your request.
  3. Hi, I am working with an issue on the Remote Operator App for iOS. The issue seems related to DNS. The following works fine: * iPhone connected to WiFi - the app connects to any active remote PLC I have tested with * iPhone connected to Cellular data, PC tethered to iPhone - PC Remote Operator connects to any active remote PLC I have tested with * iPhone connected to cellular data, app connecting to a remote PLC via it's direct IP address (not hostname) - OK Where I see the issue is with the iPhone connected to cellular data, and connecting a remote site using a dyn-dns hostname. * if I manually do an nslookup on the hostname, and enter that direct IP address into the app, it works * if I enter the hostname directly into the app and allow the app to do the NS lookup, the communication fails. I have peformed a packet trace from my phone for both types of connection. With the hostname connection, it appears that the app successfully obtains the IP address and attempts communication with the PLC, but is not successful. Hence I have confirmed the same underlying IP address is used with both the direct IP address entry and the hostname entry. However the commuincation works for the direct IP address, and doesn't work for the hostname. I have submitted this question to Unitronics support and they are working on it. I'm interested to know if anyone else has seen anything like this. Does anyone happen to have a test site set up using a hostname for access, rather than a direct IP address? Thanks, Simon
  4. Hi Neels, UniStream is only an SQL client. I'm not aware of situations where an SQL client can respond to requests. I have done some quick google searches and there are situaitons where two SQL systems are set up as master and slave where they can request data from each other, but in those cases both master and slave are both SQL servers, and the purpose is to keep backup copies of data. Just another thought, if the customer installed MQTT broker and client software on their SQL server, they should (?) be able to set up the MQTT client as a subscriber to the MQTT data, and it would push new data to the SQL databse. The PLC would only publish data as it was relevant, which would optimise the data flow to the main SQL database. There should be controllability on the update rate at both the subscriber end as well as the publisher end. Going back to the idea of the UniStream connecting directly to the main SQL databse, It is possible to set the PLC to only push data to the SQL server on change of state. Maybe the server could send an SNMP packet to the UniStream that would trigger an SQL push? As I said, just some thoughts, based on general principles and completely un-tested... Simon
  5. 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.
  6. 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.
  7. 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.
  8. I can say that the solution to this ended up being straightforward and not related to iOS or app compatibility issues.
  9. 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,
  10. 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.
  11. 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?
  12. 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.
  13. 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.
  14. 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,
  15. I would also suggest interposing relays, I think that is an all-round better option than introducing another programmable device.
  • Create New...