benS

I cannot due to IP reasons. However, I have posted screenshots of the relevant rung - I can try to make a small program later that exhibits the issue and let you check it. I Am using Unilogic version 1.32.98. This is the connection rung - once connected everything works just fine, but getting it to connect only works once on startup and never again until we cycle power. Basically, UseEthernet just a setting set elsewhere. If it's active, the client is initialized and disconnected (based off of the bit and the socket status integer), we toggle a 5 second timer that tries to connect every 5 seconds. It reads the IP address out of an IP to String HMI element, saves it into an IPAddress tag and then tries to connect. When the connection is terminated, I have a block in there that triggers whatever disconnect routine happens under the hood, assuming that this would make it so that the client can be used again. It seemed to work ok on the Unistream HMIs, so i left it in this code on the USC PLCs.

Nested structures have been one of my most desired features in this software for years. I mostly am in the OOP world and my brain generally will automatically group things into structures - on the days I do work on PLCs, not being able to then group those related things together is a huge pain. This is an industry standard feature and it suprises me that Unistream doesn't allow you to do this.

So this may just be something we have to work around, but we are using USC-B10-T24 PLCs to operate an automated test stand for a product running with a bespoke embedded controller. The Unistream will connect via a CPU TCP client over ethernet to send and receive data from this device during the test. However, once the test is completed, we disconnect the device and send it on its merry way, then get another device and repeat the process. This isn't a common use case for PLCs, which usually are set up once and never disconnected or touched again, but it doesn't seem to be working properly. Up until now, this was all handled over a serial connection, but I'm trying to have it run over ethernet due to the improved speed and stability. However, now that we are trying to have it run on ethernet, I have noticed some extremely odd behavior. The PLC will check if it is disconnected, attempt to connect to a static IP that has previously been input into the device under test, and if it doesn't connect, it will force a disconnect (thinking it would go through some type of reinitialize process), then wait 5 seconds, then try again. On the first test of the day, after power up, this connects with no issues at all. We can send and recieve data from the network stream and it works perfectly. However, once the device is disconnected, the Unistream will no longer to connect to anything on the same IP, even if we plug the same device back in. What seems to work is if I change the IP every test, then it will connect just fine. However, until the unit is power cycled, the previous IP is then useless and the PLC will refuse to connect. It will ping fine and I can connect to the device with my laptop, but the TCP connect block in ladder gets hung up on waiting for SYN and eventually times out. I only have a block of 4 IPs to use, so every 4 tests I would have to power cycle the PLC to run more. I've tried alternating target (device) IPs between one and another, multiple clients on different ports, etc., but nothing seems to work except for a hard reset. Any tips? Is there a way to reinitialize a TCP Client within the ladder?

Hi Cara, Thank you for your reply. I'm afraid I don't follow your question - Which output are you referring to, and, from my understanding of the VNC protocol, I am not sure how the VNC client is supposed to check any tags within the PLC - can you give some more detail?

Hi All, This is equal parts support request and bug / undesired behavior report. I am working on a system that has a couple of separate instruments on it - one using a custom embedded solution and one being driven off of the USC-B5. The user interface is a third dedicated, homebrew VNC viewer device that can maintain connections with the instruments and allow us to quickly switch between viewing each instrument, and send physical button presses to the instrument in question. Now, the two embedded chips communicate with each other very well over VNC - they are snappy, respond in < 50 ms with a very high frame rate, and the experience is very usable. The Unistream, however, is extremely slow to respond to any input. The screen updates quickly and works well on a display front, however, it takes about 600 ms for it to respond to any touch inputs. Once it actually recieves the touch input, it quickly processes and operates as intended, but it takes FOREVER (in PC terms, anyway) for the input to even register. This also occurs when using a PC based app as well like RealVNC or TightVNC. Has anyone noticed this? is this a potential firmware issue or is it likely on my side?

Language Test_updated.ulpr

I was able to determine it had to do with the characters given being single-bit (half width) katakana characters. When I converted it to double width characters it works fine. I'm not sure what cause that in the first place, if its a shortcoming of the Unistream firmware that doesn't support those characters or a font issue or what, but i have it working.

Hello all, I can't find a direct solution to this problem, but on our Unistream HMIs, I am having trouble with hiragana and katakana characters displaying on the screen, they display correctly in Unilogic but when downloaded to the HMI they display as boxes. I know English and traditional Chinese characters work, but i can't find a pattern with why these characters do not. I know they exist in the same character range as standard Kanji, which works, but I'm not sure if its an encoding issue or just the font isn't downloading properly or what. Anyone run into this issue that has multiple languages on their HMIs?

Yes I did. It would be one thing if it happened once but this is consistent and repeatable across every V700 I've used, and the other keyboards work fine. This isn't a gamebreaker, per se, because it functions fine, but it's annoying, and it's a regular complaint from our users.

So on the V700, whenever a numeric keypad is pulled up, I have to touch the top half of the button to get it to register. this can be kind of frustrating, because the buttons are long and narrow and it usually takes a couple tries to get it to work. I know its a software issue because there's a border that surrounds the touchable area when the button is pressed and it only covers about 60% of the button. when the button is pressed in the center, it does not register.