Doing an AJAX (Javascript, JQuery) post using MS MVC on the server

On the Javascript side, the code looks like this:

    var url = window.WEBROOT + 'InventoryItem/_Data_UpdateInventoryTransaction';
    var it = {};  // \Model\ActivityTypes\ActivityHistoryInventoryTransaction
    it.InventoryTransactionId = id;
    it.UsageQuantity = usageQuantity;
    it.LocationId = gridLocationId;
    $.ajax({
        type: 'POST',
        url: url,
        data: it,
        async: true
    });

What's going on here?

The URL says where to go on the server.   window.WEBROOT is a variable set as the page is loading, in the file shared/_Layout.cshtml, which runs every time and is provided by Microsoft.  (This is my addition to the page, of course).  Now I don't have to hard code the path through the website to the root of this web.

it is a Javascript object that mimics the structure of a class with the c# in the mvc world.  I assign values to attributes that match the c# names, and then the object is passed in the ajax call, later in the code.

The $ indicates the start of the jquery ajax call, and we pass it asynchronously.  In this case, I do not need to wait for returned data.

On the server side, in the InventoryItem controller, I have a method called _Data_UpdateInventoryTransaction which takes an InventoryTransaction object.  This object is the defined in exactly the same way as the IT object above.  At that point, I can pass the object to a lower layer, or I can use any of the data elements.

Setting up a Kendo Paging Grid

I was pulling my hair out trying to get the Grid to function nicely, with the paging enabled.  I finally went back to fundamentals, copying the format from the Kendo site.  Here is my final configuration:

        $("#ip_reportGrid").kendoGrid({
            dataSource: {
                data: myDataSource,
                pageSize: 15
            },
            height: '532',
            scrollable: true,
            sortable: true,
            filterable: false,
            pageable: {
                input: true,
                numeric: false,
            },
            columns: [

                { field: "Action", title: "Action", encoded: false, width: 205 },
                { field: "ItemDescription", title: "Item" },
                { field: "BatchDesignator", title: "Batch #" },
                { field: "SerialNumber", title: "Run #" },
                { field: "LocationName", title: "Location" },
                { field: "Quantity", title: "Quantity" },
                { field: "UnitOfMeasure", title: "UoM" }
            ],

        });

The data element 'myDataSource' is an array of objects.  Each object has elements that are listed in the columns section above.

The piece that I had been missing was the  pageSize element in the dataSource section, which indicated how many rows to pull from the datasource for every page.

Capturing an item passing on a conveyor belt

We are taking the following steps to see every time that an item passes by on a conveyor belt:

We have a PLC (programmable logic controller), but it does not need any programming, just on one line ladder logic program that says end, to allow us to put the unit into run mode.  We set up port 2 on the device at 38400 baud, odd parity, 1 stop bit and connected it via a serial port to USB converter to a PC running Kepware.

The basic Kepserver EX can be set up as a Modbus RTU Serial device, while to PLC is a Modbus  slave.  Once the communication parameters are set up to match the PLC, Kepware can monitor the PLC, looking at ports numbered 100001 and 100002.  On the PLC, these are known as X1 and X2.

We use the Kepware DataLogger to capture the changes to a MS SQL Server.  We have to create a new logger, and then identify the Kepware OPC registers we wish to monitor.  We are currently only watching the ON/OFF flag, but we can watch the timestamp to get more accurate readings, since we are only polling the PLC once a second.

These registers are mapped back to a table in the sql server, and kepware triggers (not SQL Server triggers!) are configured to write a row to the database whenever the data changes.  Our next step would be to create a sql server trigger to perform the appropriate behavior following each database write.