Customizations

The purpose of using customizations is to redirect the functionality in Balthzar in a way that is uniqe to each customer, compared to special functions, which are inteded to be used by several customers.

Customizations can be both special developed functionality as well as special functions (abbrevation SF).

As an example Vici Industries is using a combination of different SF to acchive the deseried functionality according to a "dust shutter principle" described below.

Background

An active machine which is constantly producing articles is usually not shutdown between different orders. However you wan't the orders quantity to be applied to the correct order in order to get a correct follow up. The normal procedure here would be to stop the machine, print the order, start a new order and then start the machine. But thanks to a comibnation of SF, 25, 30, 31 and 33 we have solved this issue.

SF 25 Group orders

SF 25 will let you group orders after the first one is started as if they were all started at the same time. (They will all get the same start date as well.) Read more about SF 25 here.

SF 30 Warning, order done

SF 30 will warn the operator that it is time to change the order. This will happen when the produced quantity is equal to, or bigger, then the produced quantity. The effect of this is that the "dust shutter principle" will activate. Transactions registered after this will be registered on the next orders. In order to get this function to operate as effectivly as possible you have to change settings in Balthzar Collector so that each individual cycle is automatically registered instead of all cycles at once, which is standard. This is done when you change "Direct qty save" to "yes" in the "Edit Machine" menu. See picture below.

 

If theese changes are not made a bunch of cycles will be reported simultaneously and this will prevent Balthzar from giving the warning in time.

It can seem logical that the standard settings should be to register every transaction in real time, but the reason this is not the case is that it would cause an unnecessary large amount of transactions which would cause an unnecessary large amount of  load of the Balthzar SQL server. As an example we can calculate that if Balthzar would calculate the quantity of cycles during 30 seconds and then send 10 as a value of quantity of cycles this will be more resource effective then to create 10 seperate posts in the database. If you would add more machines and they would use the same functions the problem would increase even more. The limit of the number of machines which can use theese settings depends on the hardware used by the SQL server.

You can read more about SF 30 here.

SF 31 Simultaneous ending of orders

Since all orders is given the same start time because of SF 25, Vici also wan't all orders running simultaneously to have the same end date. When an order is ended all other orders will be ended at the same time.

You can read more about SF 31here.

SF 33 Start order next to previous

When a new order is started it will recive the same start date as the previous orders end date. This set up is a demand in order for the customization to work properly. The reasoning behind this is that in order to deal with eventual "surplus" in the production done in the first order started, the times when transactions are started is matched, to the time when a specific orders is complete. In order to do this match all orders currently running must be started and ended next to each other. Order 1:s end date will be the same as order 2:s start date even if that is not the case in reality.       

You can read more about SF 33 here.