Field Electronics

[FrankJ]

They are using panelviews & I assume an Allen Bradley PLC to tie all the logic together. The programming tools you need to change any of the source code is very expensive & has a bit of a learning curve. Unless you know somebody that already has the tools, that is another cost to factor in.

All in all, a lot of cost for something that is going to change in Jan.

[Johnny_5]

On the PLC I am not 100% about that. I believe that the I/O units are all based on TCP/IP comm protocol, so a PLC may or may not be required.

I see no reason to change the source code that any of the control devices use. But the tools and software are available to us if that is a route we choose.

You bring up a question that has been biting at me for a while. Is the scorer interface the same year to year? Are there always ( in the past ) been a human scorer using Panelview's to input the scores to the field? This is a factor that would definitely make or break the possibility of a full field for us.

[Vikesrock]

Originally Posted by Johnny_5

You bring up a question that has been biting at me for a while. Is the scorer interface the same year to year? Are there always ( in the past ) been a human scorer using Panelview's to input the scores to the field? This is a factor that would definitely make or break the possibility of a full field for us.

No, this is the first year Panelviews have been used.

[Johnny_5]

How was the interface done last year?

[dag0620]

For Example:

Last year, there were sensors (It was some form of motion sensor, not sure on specifics) that more or less triggered when a soccer ball was scored through a goal.

Another of those sensors were then placed on the return racks, to make sure all the soccer balls got returned within 10 seconds, or else DOGMA Penalties were issued.

Those were I believe were hooked to a IO Modual in the SCC (There may have been a smaller IO Box like this year, but memory is getting to me)

The finale with robots hanging was manually inputted at the scorers table.

So as you can see lots of variation in electronics from 2 back to back years. This is why making a full set can become very expensive if you try to update it. To run the basic setup of getting the robots to run (router, bridges, lots of cat 5) is one thing, but beyond that, it's hard.

[Mike o.]

Originally Posted by Johnny_5

On the PLC I am not 100% about that. I believe that the I/O units are all based on TCP/IP comm protocol, so a PLC may or may not be required.

I am not too sure about that. I do believe that there is a fair amount of PLC programming that is loaded onto the I/O blocks. The type of I/O blocks that they are using typically are configured through the RSLogix Software. The reason for this is that using the PLC programming helps to manage any sort of sequence of events in a more reasonable fashion. Its a nice and easy way to take all the inputs and sort out the proper actions to take and report back to the FMS a clean, clear output.

[Johnny_5]

Mike-
True, as I look at it a little bit more I realize that is most likely some sort of PLC code that is embedded into the IO units. One reason I think there is now is because inside the full FMS there is a PLC heartbeat monitor. So maybe there is some sort of PLC that simply just combines all of the events into one string and sends it along to FMS

Dag0620-
So it seems a little pointless to go off and start building one with this years game specific equipment on it from the get go. But my original goals could still be adapted into this. We could build the field like we originally planned a few months ago and not put on any of the game specific electrical or physical equipment. And then after next years game and field equipment is announced we could go out and borrow some of the Panelview terminals if they are using those again or install the motion sensors should they go that route.

One more quick note. The more I think about it the more I realize that those Panelview terminals are most likely running Windows CE on them. So it may actually not be a RA software thing for the terminals, it could just be a windows program

[FrankJ]

Typically remote IO have very little if any user logic programmed into them. What have is node address (IP address if TCIP), who can write to them, that kind of stuff. I/O health is already there is some form. In industrial equipment, monitoring the health of your IO is routine.

Rockwell (IE Allen Bradley) is a strategic sponsor. If they are donating the field hardware and they view it as an type of showcase, it will not be low end stuff. Not that Rockwell has a lot of low end stuff to begin with...

If I were FIRST person responsible for the field design, I standardized as much of the back end as possible from year to year. Different sensors for scoring is really a small thing. Scoring logic & different screens for the panelviews is all programming.

[Johnny_5]

Frank-
That is what I originally thought. I did a lot of thinking before evening considering embarking on the idea to build a field. I realized that while some components will change over the years the whole concept will still revolve around IO for the entire system. While it will still be a costly endeavor to build the field and implement the electronics such as the SCC's and Scorpion Case it will not be too bad. So assuming we actually are able to start this project by mid June or July it could be quite a while till it is done.

[rsisk]

The scoring panels this year were running what looked like a version of Windows. An application would launch to all the scores to be entered via touch screen. These were then connected via ethernet cable to the ethernet switch in the SCC.

There were also a pair of DMX boxes controlling the lights in the tower. A harness of wires from two towers were run to the DMX box. I'm sure the harness contained wires for the lights at the base and the top as well as the signal switch at the top of the tower. The DMX boxes were connected to the SCC ethernet switch as well. The DMX boxes were also linked to each other via a 75' ethernet cable.

[Johnny_5]

Yup, sounds exactly right. There is a program inside FMS that sends ethernet packets to that controller which converted into DMX which operate the dimmers to control the lights

[Mike o.]

Originally Posted by rsisk

The scoring panels this year were running what looked like a version of Windows. An application would launch to all the scores to be entered via touch screen. These were then connected via ethernet cable to the ethernet switch in the SCC.

There were also a pair of DMX boxes controlling the lights in the tower. A harness of wires from two towers were run to the DMX box. I'm sure the harness contained wires for the lights at the base and the top as well as the signal switch at the top of the tower. The DMX boxes were connected to the SCC ethernet switch as well. The DMX boxes were also linked to each other via a 75' ethernet cable.

The lights at the base of the tower were connected to the DMX Controller. The AB Signal Lights and the trigger at the top of the tower were all harnessed together and connected to another AB ArmorBlock I/O Controller.

As far as the PanelView Application for the scorers, it is a program that was built in AB's FactoryTalk View.

[Johnny_5]

Originally Posted by Mike o.

The lights at the base of the tower were connected to the DMX Controller. The AB Signal Lights and the trigger at the top of the tower were all harnessed together and connected to another AB ArmorBlock I/O Controller.

So that makes a little more sense, I had just begun to question how it triggers a certain light bar to stop after an input is sensed.

[jtdowney]

Originally Posted by rsisk

The scoring panels this year were running what looked like a version of Windows.

Yep, the ones I setup at Boilermaker were running Windows CE.

[Johnny_5]

jtdowney-
Is there any information you could give to me about the field? Like about equipment used or how things connect together