(upbeat music)
- [Instructor] Now that we've added a device to our project,
I want to show you what fields are being populated
in the databases.
Ideally, you'll rarely need to make manual changes here
as my recommendation is to stick to the I/O Device Manager.
But there will be troubleshooting situations
where this information will be useful.
I'll begin with my I/O devices database.
Each record in this database points to a source of data
on the network, as well as some system devices
on the server.
Here, we see the name we added in the I/O Device Manager,
the protocol, and the Modbus address.
Different drivers using different protocols
use the various addressing fields and databases differently.
PowerModbus sets its Modbus address
in this address field.
Then references a port in the ports database
found under components and mapping.
This port contains the IP address in special options.
ION devices communicating over Ethernet, by contrast,
store their IP addresses here in the I/O devices database.
And they all reference a single ION port.
I say this as a warning that finding a device's address
from the databases may take some hunting.
In an upcoming video, I'll show you my preferred method
to keep track of the devices.
The other reason to bring you here is for this Memory field.
If I set this to TRUE,
the device will be put into memory mode,
meaning the runtime will not attempt to communicate
to the field device and will not throw
a communications failure alarm.
I can write my own values to the memory mode device,
however, making this field invaluable for testing.
That does come with its own warning
when restoring a project, of course.
If you aren't reading real data,
make sure your devices aren't in memory mode.
The next database to see is Equipment
under the System Model.
Here's the device I added and the type is its profile,
which is a useful troubleshooting tool for verifying devices
were added correctly.
There are a number of other fields here
used in various places,
but note that the equipment record points to
a single I/O device.
In another video, we'll look at a situation
where we have multiple equipment
referencing the same I/O device.
Next up are the variable tags that we selected
in the Profile Editor.
The Tag Name is formatted as I/O device slash tag name.
We set the Equipment and I/O Device
in the I/O Device Manager and the rest of the fields
come from the Profile Editor.
The only other tag I'd like to point out is this EEHealth.
It's associated with our equipment,
but is read from a system device called NetworkTagsDev.
This tag is populated by the I/O server in runtime
and is used by the communication failure alarm.
It's managed automatically by the I/O Device Manager,
and generally shouldn't be modified or removed.
The other tags, we'll review in later videos.
But I'll point out that if we added any onboard alarms,
PC-based alarms, or trends in our profile,
there will also be tags populated under these two tabs.
This was a brief look at the final output
of the Profile Editor and I/O Device Manager.
I don't expect you to work directly in the databases
too often, but it's important to know
where the configuration is so you can,
especially when you start troubleshooting.
In the next video, we'll get back to the I/O Device Manager
and look closely at what happens when you update a device
in the databases.
Until then, thank you.