I need clarification and guidance - consider me a total noob

• 

  Corey B

  February 27, 2021 22:52 (Edited March 04, 2021 17:32)

  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')
  end

  
  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;
        listen_to_drill(command_data->drill_id);
      }
    }
  }
  
  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,
      "drill_update",
      "4s1 temperature 4f1 angle 4f1 rpm",
      &status,
      sizeof(status)
    );
  
    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
    end
  
    ui_update['drill_status.drill_angle.text'] = angle .. ' degrees'
    ui_update['drill_status.drill_rpm.text'] = rpm .. ' rpm'
  
    gre.set_data(ui_update)
  end

  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!

  Cheers,
  Corey

  0
• 

  Adam Ackerman

  March 02, 2021 15:06

  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. 

  0
• 

  Corey B

  March 04, 2021 17:46

  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.

   

  0

Please sign in to leave a comment.