Messages

1

Open Discussion / Re: Driver Siemens with Snap7

« on: June 21, 2022, 01:28:33 PM »

I know this thread is almost a year old but had there been any more development on this driver? Has it been tested with S7-300? As our company has been growing over the years all our new equipment has been coming in from Germany and its all Siemens..

Thanks

I've been using the Modbus driver succesfully but with S7-1200 and S7-1500 and works pretty well, with almost all the functionallity of all the other drivers. I do not know if S7-300 supports it. You only have to write code in VB to convert values that are not integers, like strings. I can share some code I used if want.

2

Open Discussion / Re: Write float value in CLX Ethernet/IP

« on: May 09, 2022, 12:37:38 PM »

Something's funny, "F8:" is not ControlLogix syntax, it's SLC syntax.

Can happen when you migrate projects!

3

Support Questions / Re: Siemens "LOGO" 12/24RCEo

« on: March 31, 2022, 06:47:28 PM »

Try using ModbusTCP server in Siemens. If you have to transfer something different than integers, you will have to write some code to convert data, depending on the format. It works pretty well.

4

Open Discussion / Rockwell Automation products unable to establish DCOM conn after patch

« on: March 01, 2022, 11:12:37 AM »

This was sent to me by our senior CE. Just sharing with you guys, I do not know if this has any effect over AHMI or its usage with OPC servers.

5

Tips & Tricks / Re: Changing Com Component

« on: August 23, 2021, 09:42:43 AM »

Your 5/03 was using the serial port to communicate with AHMI? Because as far as I know there is no component to communicate through DH+.

The SLC 5/03 does not have a DH+ port, only the 5/04 does.  The 5/03 has a DH485 port.

You are correct, my mistake. But still should be the same situation, as he is using DF1.

6

Tips & Tricks / Re: Changing Com Component

« on: August 20, 2021, 06:12:03 PM »

Another option is to use the find and replace on the project, to change the com component name in all controls.

7

Tips & Tricks / Re: Changing Com Component

« on: August 18, 2021, 02:37:34 PM »

Your 5/03 was using the serial port to communicate with AHMI? Because as far as I know there is no component to communicate through DH+.

If so, and if you were using AHMI and the SerialDF1forSLCMicroCom, then it should be just matter of change each control's com selection after setting up your Ethernet com control. If you have too many visual controls that require this change, try by selecting all those who are the same type (like all the basiclabels) and see in the propierties page if the common controls can be changed.

8

Support Questions / Re: CLX driver intermittently does not update

« on: August 18, 2021, 02:30:51 PM »

Which suggestion did work? First, second or both?

9

Support Questions / Re: Error stops hmi execution

« on: August 16, 2021, 09:39:54 AM »

Google for VB.net Try Catch, that is what you need to learn how to use.

10

Open Discussion / Re: Press Integration

« on: August 16, 2021, 09:16:33 AM »

Isn't tag tree read a new feature Archie just added to latest beta?

11

Application Showcase / Re: Custom Trending with SQLite

« on: May 17, 2021, 03:31:47 PM »

Interesting. Have you ever tried MS Power BI?

Yes quite happy to share code.  I would just have to go back through my projects and find it.

However, I wouldn't reckon doing this, it took hours/days of code writing and not to mention the maintenance.  I have since discovered InfluxDB, Grafana and Node Red. 

InfluxDB is a purpose built time series database built for trending historical data, grafan takes out all the hard work with querying databases and it provides visually appealing dashboards.  Combined with node-red it takes roughly 5 mins to set this software stack up compared to hours/days of tinkering in Visual Basic code.

If you would still like the source code let me know.

12

Open Discussion / Modbus registers and coils, how they work (is not a question).

« on: May 04, 2021, 09:29:59 AM »

For all of us who are not versed in Modbus, I received a bulletin from RTA Automation with this very practical description on how it's based, so I wanted to share it. Hope is useful for someone.

Registers and Coils

Coils are single bits. They can be ON (1), or they can be OFF (0). Some coils represent inputs, meaning they contain the status of some physical discrete input. Coils can also represent outputs, meaning that they hold the state of some physical discrete output signal.

Registers are 16-bit unsigned register data. They can have a value from 0 to 65535 (0 to FFFF hexadecimal). There is no representation for negative values, no representation for any values greater than 65535, and no representation for real data such as 200.125.

Applications can impose these representations on registers. For example, an application can treat two registers, the first containing 200 and the second containing 125, as 200.125. Any application can organize and treat register data in any way it may want, but there is no way for any other Modbus device to automatically know what that representation is. A Modbus application that reads registers from a Modbus slave device must have some prior knowledge of how particular registers are treated to process them correctly.

Registers are grouped into input registers and holding registers. Like input coils, input registers report the state of some external input as a value between 0 and 65535. The original intent of an input register was to reflect the value of some analog input. It is a digital representation of an analog signal like a voltage or a current. Most Modbus devices today are not I/O devices and input registers simply function identically to holding registers.

Holding registers were originally designed as temporary program storage for devices like Modbus controllers. Today, holding registers function as data storage for devices. Both Modbus registers and coils are addressed with the first register or coil as Address 0 and the last as Address 65535. That means that there can be up to 65535 (FFFF Hex) input registers, 65535 output registers, 65535 input coils and 65536 status coils, but most devices use far fewer. The typical address space notation used in Modbus follows:

0x is Status Coil Address Space from 00000 to 065535
1x is Input Coil Address Space from 10000 to 165535
3x is Input Register Address Space from 30000 to 365535
4x is Holding Register Address Space from 40000 to 465535

When you see a notation that some value is at Modbus register 40010, you know that the value is stored in a holding register at offset 11, the 11th value, in the holding register area of the device. When a Modbus device is designed, the designer makes a decision of not only how many registers or coils are needed, but also which address space to use (input coil, status coil, input register, holding register) and where in that address space to locate those values. That example points to one of the deficiencies of this data representation. There are no standards.

There is no way to communicate to the user of the device any metadata. If the value of register 40100 is a temperature, there is no standard way to communicate the meaning of register 40100 and how to interpret the data. The user has no information to know if a value of 1001 means 100.1 degrees or 10.01 degrees or 1001 degrees. There is no standard regarding device profiles. Another temperature controller may store its temperature at 40200 and use a completely different data interpretation. The Modbus data representation is simple and almost standards-free. That is both a blessing and a curse to those of us who still use Modbus daily.

13

Open Discussion / Re: Driver Siemens with Snap7

« on: November 09, 2020, 09:44:22 AM »

Great! I will try it as soon as I have another project with Siemens, which will be within the next three weeks.

14

Open Discussion / Re: Ways of upgrading older solutions to newer versions of Advanced HMI?

« on: November 06, 2020, 11:39:42 PM »

Seems to work fine by the exception of datasets, I used the same method but those created a lot of errors and cannot be opened like in the original project. Do you know if there is another method to import them into the new project?

15

Open Discussion / Re: Ways of upgrading older solutions to newer versions of Advanced HMI?

« on: November 06, 2020, 05:41:49 PM »

The easiest way to upgrade to a newer version:

1) Open a blank project in the new version
2) Right click the AdvancedHMI project in the solution Explorer
3) Select Add->Existing Item
4) Browse to the old project and select all of the forms vb files (there will be 3 files for each form, only select the .vb file)
5) Manually go to each error and correct

This works well unless crossing the 3.5 boundary. If upgrading from a pre-3.5 to a post 3.5, you will get a large number of errors because of the property changes.

I want to update a project from v3.9.9t to current version 3.9.9yBeta36. Is this still the best way possible? I'm using three drivers of EthernetIPforSLCMicroCom, and want to add a ModbusTCP to connect to a Siemens PLC. Do you foresee any issue with that combination of drivers? I want to update as I've seen that Archie did some fixes and improvements since v3.9.9t to ModbusTCP.