I need clarification and guidance - consider me a total noob

There are a few things I am not understanding and I am sure that is due to my in-experience with this design concept.  My background is 2 years of windows desktop hardware support and then jumping into the industrial automation control world at the HMI GUI development level with no prior training for a OEM. 98% of my experience has been hands on learning, on the fly, with Rockwell Automation Factorytalk View Studio in both Site Edition and Machine Edition, that last 2% was a single Siemens job we stumbled our way through.

What I am not understanding and not able to find any detailed information on is how external data is connected and communicated in Storyboard.  I am used to working with PLC controllers and ladder logic, structured text is not a new concept for me but the addressing I am used to seeing probably differs greatly from the practice used in applications like Storyboard. I can work my way through ladder logic and find the "tags" I need but part of that is because our tag structure for touch screens is specifically unique compared to the rest of the logic we use. 

I assume this is a place where I need a OPC to do the translation between the tag structure in the Allen-Bradley controller and the storyboard IO connector, but again I don't see how I get from Storyboard to the Rockwell Gateway software - or to any external source for that matter.  Even if I was using Basic on a BeagleBone Black I don't see where that addressing occurs in Storyboard.

obviously I am missing something that is in most cases very clear, but I think I lack the experience in this side of Automation control to make the information connections I need; can someone point me in the right direction? 



  • Hi Adam,

    I think the thing you're missing is that Storyboard's IO model is event driven.  So you may be trying to search for data addressing schemes directly on the IO layer but you probably won't find any that look familiar.  It is up to the developer to build a more application specific transport over the base SBIO event mechanism.  If you haven't already, you could take a look at the sample projects (there is a button in Designer to browse them) to see if anything is similar to what you're trying to do.  The other thing that may not be clear is that Storyboard is used in a wide range of situations (home, medical, industrial, automotive) and the primary focus is to provide an efficient and elegant way to interact with the user (get touch input, show fancy graphics) on an embedded system.  So if you're looking around the docs assuming that the whole product is about industrial control, that may be throwing you off.

    Although many developers do build their entire application state and communication layer directly into their Storyboard project and that works fantastically in a lot of situations, another common approach is to have running on the same board, a separate process that is handling the 'business logic' of your application. For example, you might be provided a C library from FactoryTalk that does the normal data listening/sending to the Rockwell gateway. You could look at our C/C++ Storyboard IO documentation (https://support.cranksoftware.com/hc/en-us/articles/360057414271-Storyboard-IO-API) for how to write a C program to send events and even can address your Storyboard controls directly to inject data into your UI. I am not personally an expert on industrial control so one of my colleagues may be able to correct me here but I understand the data rates can be very high in some cases. A common pitfall is to try and pass the entirety of the data to the UI as fast as you're getting it. Storyboard will try and update the graphics as fast as it has new information, combined with processing data it doesn't need can lead to high CPU load. This middle layer is a good place to filter and manage your data and adapt it (look into the model-view-adapter paradigm, slightly more applicable here than the ubiquitous model-view-controller).

    [v]=[a] ----- [m]

    = - Storyboard IO
    ----- - Eth/WiFi/Zigbee/etc

    v - View - Storyboard Engine running your gapp
    a - Adapter - C utility that has knowledge of the data model, a library to communicate with the Rockwell gateway, a library to communicate Storyboard Engine and a header to go with your Storyboard app (generated in Designer based on your project), and some state knowledge of what data the UI currently wants (or what user driven machine control operations are currently available).

    m - Model - The structure of your data and how to access it. This is your target machine's state that is made available through the gateway, for example.

    If the model is not on the same physical computer, then the adapter will also need to handle that communication layer. Usually the adapter is made to communicate within existing system design and hopefully you can reuse something else that you're more familiar with or have already written for this piece.

    For the SBIO (Storyboard IO) side, you'll want to plan ahead and decide a set of events (API really) that make sense for your use case. Eg. If you have a screen titled "Drill Status", and as a use case it shows temperature, angle and rpm of drill #3, then you might have two events defined to handle that.
    View->Adapter listen_drill(int drill_id)
    Adapter->View drill_update(int temperature, float angle, float rpm)

    The view side selection is implemented in Lua running in your app on sbengine:
    (somewhere in a callback chain, eg. screenshow_pre event firing a Lua Action)

    function show_drill()
    local drill_command = {
    drill_id = 3

    gre.send_event('listen_drill', drill_command, 'factorytalk_adapter')

    The adapter side of the state selection is C/C++, using our provided libgreio library.
    (global or class member)

    gre_io_t* gui_handle;

    struct listen_drill_command {
    int drill_id;

    union command {
    struct listen_drill_command;
    // put other commands/events here

    struct drill_status_data {
    int temperature;
    float angle;
    float rpm;

    int monitoring_drill_id;


    (somewhere in your init code)

    gui_handle = gre_io_open("factorytalk_adapter", GRE_IO_TYPE_RDONLY);


    (main SBIO receive loop)

    gre_io_serialized_data_t *buffer;
    *buffer = NULL;

    char** event_target;
    char** event_name;
    char** event_format;
    union command *receive_data;

    while(1) {
    int bytes = gre_io_receive(gui_handle, &buffer);
    if (bytes > 0) {
    bytes = gre_io_unserialize(buffer, event_target,
    event_name, event_format, (void **)&receive_data);

    if (!strcmp(event_name, "listen_drill")) { // we have a drill_update event
    struct listen_drill_command* command_data = (listen_drill_command*)receive_data;

    function listen_to_drill(int drill_id) {
    ... // do relevant stuff on the Rockwell side
    monitoring_drill_id = drill_id;


    (main Rockwell receive loop)

    ... // process incoming drill data. This is specific to your system.
    // We'll assume you end up with some data packed into variables are able to make a function call like this:
    update_drill_status(temperature, angle, rpm);


    (in the SBIO code in the adapter)

    function update_drill_status(int temperature, float angle, float rpm) {
    gre_io_t *send_handle = gre_io_open("cnc_monitor", GRE_IO_TYPE_WRONLY);

    struct drill_status_data status;

    gre_io_serialized_data_t *nbuffer = NULL;
    nbuffer = gre_io_serialize(nbuffer, NULL,
    "4s1 temperature 4f1 angle 4f1 rpm",

    gre_io_send(send_handle, nbuffer);


    Back on the Storyboard Engine side, now receiving the status from our adapter.
    In Storyboard Designer, create an action that fires on incoming 'drill_update' which calls cb_drill_update() in Lua (https://support.cranksoftware.com/hc/en-us/articles/360056943392-Connecting-Events-to-Actions). Remember to set your running engine to listen on the channel you've chosen for the user interface ('cnc_monitor' in my example), see (https://support.cranksoftware.com/hc/en-us/articles/360056943732-Sending-Events-to-a-Storyboard-Application)

    local COLOR_RED = 0xEE1111
    function cb_drill_update(mapargs)
    local status = mapargs.context_event_data
    local temperature = status.temperature
    local angle = status.angle
    local rpm = status.rpm

    local ui_update = {}
    ui_update['drill_status.thermometer.level'] = therm_height * (temperature/MAX_TEMPERATURE) -- visual indicator, bind eg. A Fill's grd_y val to level.

    if temperature > WARN_TEMPERATURE then
    ui_update['drill_status.thermometer.color'] = COLOR_RED

    ui_update['drill_status.drill_angle.text'] = angle .. ' degrees'
    ui_update['drill_status.drill_rpm.text'] = rpm .. ' rpm'


    Check out (https://support.cranksoftware.com/hc/en-us/articles/360056943772-Storyboard-IO-Utilities) for info using standalone utilities to test your SBIO API. Some developers choose to use those utilities for production as well, instead of writing C code. There is also a tool right in Storyboard Designer to test event handling (https://support.cranksoftware.com/hc/en-us/articles/360057413151-Using-the-Storyboard-IO-Connector)

    This is simply and idea of how I would approach it, not a necessary construction. Hopefully that gives you something to get started. The first step would be compiling a bare bones C program that can talk to your hardware/gateway, then bring Storyboard into the mix. If you have an example of how you are able to programmatically send/receive data with your gateway, we can give you advice on restructuring that for your UI. An alternate approach would be to do UI field manipulation more in the C app, and use gre_io_send_mdata() to directly set UI data variables. Let us know it goes!


  • Corey,

    I very much appreciate the response here, that is some great detailed information.  It is all way above my head but luckily I have a software developer who understands the concepts and what we need to do; we are certainly going to move forward with a basic test application to see how this compares to our current solution. 

  • No problem, happy to help clear it up.  Good luck!  Please don't hesitate to ask if you hit any roadblocks or need further clarification on anything.



Please sign in to leave a comment.

Didn't find what you were looking for?

New post