Nightfly

Depends how accurate you want it, but you could always periodically simply increment a DINT. Have one that counts up every second (no need to reset as it’s good for over 60 years). When something starts, copy the value of the DINT to a “start time” Register, same when it stops. The time in seconds is obviously stop time – start time.

  For an E610 HMI you use a Beijer CAB5 cable (simple three wire). For an E1061 you use a Beijer CAB30 cable.

  As far as I know it is a compiled resource file, the contents being bespoke to Beijer.  

Hi, If it can't match the driver then have you any Mitsubishi PLC drivers actually installed? There is an option to update them under the File menu. Select File->update Exter drivers from the internet (or something like that). Select all the Mitsubishi ones and download them. As far as I recall (and I could be wrong), originally Exter HMI’s could not be used with Mitsubishi PLCs because of a Beijer contract to supply the same units to Mitsubishi badged as the E1000 series. So they removed the drivers. However, this changed later when the two companies fell out. You may just not have any drivers installed.  

The HMI you are trying to program is a Beijer Exter, You need the program “Information Designer” to do this not E-Designer. E-Designer is used only for Mitsubishi HMI’s (I know the HMI’s look Identical but they do need different apps to program them). You will also need to convert the project so Information Designer can read it. I wrote a small App to do this a few years back. It can be found in the downloads section of this site.   Warnings about file creation versions and different driver versions can usually be ignored and the HMI once converted and loaded into the HMI will work perfectly fine.

As Neverov said, all the addresses are screwed up. For example if you want to read outputs then they are sub 1000. Output frequency is at address 201, amps is 202, thermal overload % is 210 If you wanted to change the minimum speed parameter you would write to address 1002   Also (as Neverov said), the slave address must be set to 255 otherwise it will just ignore requests. I have found that on many Modbus communication applications this is not an option for TCP. The free qmodmaster does have it though, and is what I have always used to test comms om Mitsubishi Inverters https://sourceforge.net/projects/qmodmaster/   The settings below are what I have used before for reading data into a PC using Modbus TCP. These setting just allow monitoring and the read/Write of the parameters. They do not allow you to control it (turn it on/off) as this was done via digital inputs.   73 Analog input selection 0 77 Parameter write selection 2 79 Operation mode selection 2 160 User group read selection 0 161 Frequency setting/key lock operation selection 0 178 STF terminal function selection 60 179 STR terminal function selection 61 180 RL terminal function selection 4 181 RM terminal function selection 9999 182 RH terminal function selection 9999 195 ABC1 terminal function selection 99 196 ABC2 terminal function selection 98 502 Stop mode selection at communication error 4 550 NET mode operation command source selection 9999 551 PU mode operation command source selection 9999 779 Operation frequency during communication error 15 1424 Ethernet Communication Network Number  1 1425 Ethernet Communication Station Number 1 1426 Link speed and duplex mode selection 0 1427 Ethernet function selection 1 5001 1428 Ethernet function selection 2 45237 1429 Ethernet function selection 3 502 1431 Ethernet signal loss detection function selection 3 1434 Ethernet IP address 1 192 1435 Ethernet IP address 2 168 1436 Ethernet IP address 3 100 1437 Ethernet IP address 4 1 1438 Subnet mask 1 255 1439 Subnet mask 2 255 1440 Subnet mask 3 255 1441 Subnet mask 4 0   What is the reason you are connecting the inverter to the PC?  

If it streamed data to the PLC continuously then I would query the use of the Bidirectional Protocol. Did you read that this was required somewhere? I would assume Bidirectional may want handshaking other than the software XON/XOFF that your 3 wire connection can give (and if it was streaming continuously to the PLC without software handshaking then the Scales are not using it). If so this could be why you are not receiving data. For streaming data perhaps the Non Procedure Protocol is the way to go.  However, you will probably have to format the data yourself and often even have to find it in within the data array received.

Regardless of the serial device (RS232/422/485) I always feed it into a PC first to see what’s happening.  I wouldn’t bother with all the jumpers, just wire 3-2, 2-3 and ground and monitor with your favourite Serial port Monitoring tool (there are a few free ones about). It takes out a lot of the guesswork as you will be able to confirm that the Scales are actually streaming the data, as well as the format it is in (but you will need a serial to usb adapter).

VNC is useless if you are trying to show a single screen continuously.  This is all really basic stuff, are you new to this (this is not a criticism as we all started somewhere)? If you can connect via Ethernet then simply get another HMI to show the data you need. Frankly it doesn’t need to be a GOT, there are cheaper options out there – especially if IP rating is not an issue (the only reason to us a GOT in my opinion).

  Well normally you would just configure another port on the PLC and simply connect the new HMI to that. Is there a problem doing this? We have often shared a port for overview screens without problems.  Usually this has been on Fx PLC’s specifically on the old E-NET module where ports are limited. Yes it can slow the HMI’s down if you have them both polling rapidly. However, if you change the overview screen to only update every few seconds then normally it’s not a problem. On one site we have an overview screen polling 14 different PLC’s using this method (because all the other ports on the 14 machines are being used by OPC or direct PLC to PLC communication). Only works on certain protocols though.   What PLC are you using?  

You can enable the web server and pull data in real time, alternately you could set up the data logging function in the HMI and save the data to a CSV file. Then copy the file over to the PC via FTP. Both solutions will work fine.

  You could always ping the PLC first to see if it is online? When you say it freezes what do you mean? Are you creating the Mx instance on the GUI thread - if so that’s probably why it is freezing. Stick it in a separate thread and it can hang all day if it wants and it won’t affect the GUI. If you are just wanting the PLC and Robot to talk to each other have you considered using a protocol converter?  We have used the Beijer Box 2 range quite a lot for such things (the base model we get for just over £200) and it includes drivers for around 80 different protocols. There are other similar devices (Red Lion for example) but we prefer these because you can add your own C# code to it (to cache data etc).        

Perhaps it has improved over the years but we gave up on MX Component about 10 years ago for similar reasons (think this was on version 3).  We found that it just wasn’t reliable when communications fell over – usually because the guys on the shop floor had turned the machine off/on. If I remember correctly we ended up having the PLC send a watchdog value that incremented once a second. We had the PLC Mx communication on one thread, and another monitoring thread checking for the watchdog value to change over time. If the watchdog value didn’t change then the monitoring thread killed the Mx thread and started a new one up. Not ideal by any means but it sort of worked ok. We moved on to using kepserverex OPC and later to getting the data via the HMI (as it saves the cost of an OPC Sever and can also cache the data for when the PC is down).

This bug was fixed in 7.52 build 363