Tag Archive: hardware

Expansion Module Cabling

Any expansion module used with the JNIOR Controller needs a way to connect to it. On each JNIOR is a sensor port which allows a cable to connect from the expansion module to the JNIOR. These are 6 Pin Modular Flat cables and they use RJ-12 connectors. These cables are supplied with the purchase of an expansion module. The length of the cable that comes with each expansion module varies depending on what expansion module is purchased. 

These cables can be made by anyone. All that is needed is a 6 Pin Modular Flat cable, two RJ-12 connectors, and a crimp tool. We have tested a cable length of 100 feet with one module, but the number of modules impacts the maximum length the cable before failure. If the cable is too long, either the expansion module will lose power, or it will no longer receive data from the JNIOR to operate correctly. Testing and validation of the cable is up to the customer and INTEG provides no guarantees for the functionality of the modules when custom cables are used. If you are interested in making your own, here are some links to these items:

6 Pin Modular Flat Cable

RJ-12 Connectors

Any crimp tool should work just make sure it’s able to crimp for RJ-12 connectors.

By | On August 4, 2023 9:55 am | No Comments |

JNIOR Relays – Normally Open vs. Normally Closed

The JNIOR has Dry Contact Relays.  Dry contact relays must have power supplied from an external source.

The relays can be set for Normally open or Normally Closed operation.  They are normally open when manufactured.

Controlling the relay is the same regardless of the mode that they are in.  Switching the relay to be Normally Closed basically causes the relay to be inverted.  When you command the relay to close it will open.  Sounds backwards right?  By commanding the relay to close you are basically energizing the relay.  Energizing the relay puts it in the opposite state from its normal condition.  Normally Opened relays will Close and Normally Closed relays will Open.

There are internal jumpers that allow you to change the operation of some of the internal relays depending on the model.  On the Model 410 and Model 414, output channels 1 and 2 have jumpers to select the mode of operation.  The Model 412 and Model 412 DMX have outputs channels 1, 2, 9, and 10 that can be either Normally Open or Normally Closed.

To change the relay from Normally Open to Normally Closed you need to open the JNIOR and move the factory supplied JNIOR from the outer most pins (as shown on the upper jumper) to the innermost pins (as shown on the lower jumper). 

Shows the jumper position for outputs 1 and 2 on a JNIOR 410

The Power 4 Relay Output Module has both the Normally Open and Normally Closed pins available on the connector.  There is no need to move a jumper.

Power 4 Relay Output Module. Normally Open / Normally Closed Side View.
By | On August 23, 2021 12:21 pm | No Comments |

Temperature / Humidity Sensor
The Temperature / Humidity Sensor with Cable

INTEG resells a Temperature / Humidity Sensor that is manufactured by Embedded Data Systems. We often refer to this as the Environmental Sensor. As part of the offering from INTEG you get a 12′ cable with an RJ-12 connector that is tested to work with the JNIOR. We also had to create certain applications that work with the module. JANOS only natively supports INTEG expansion modules.

To wire the sensor you will need 3 wires that are for Power, Ground and One Wire Data. Even though the JNIOR uses an RJ-12 connector with 6 pins, only 3 are needed.

In the picture below you can see the 3 wires that are connected. We wire the flat black cable through the side of the sensor. The sensor does come with a mounting plate with a hole in the center. If you wire the unit yourself, you can use that hole for your installation. We chose not to use the bracket so that the device can be mounted flush without the need for rewiring or cutting a hole in the wall or surface.

Humidity Sensor expansion module for JNIOR

A closer look shows us the connection in the terminal block that each wire is connected to. As with INTEG modules, this terminal block gives you the ability to daisy-chain multiple devices.

Wiring for JNIOR Humidity Sensor

The wire needed is a modular flat 6 conductor cable. We use this one from digikey. The other end of the wire is the RJ-12 connector. We use pins 1 – 3. With the connector tab up you can see that the wires in use are on the right.

Wire end for expansion module sensor cable
By | On September 18, 2019 12:42 pm | No Comments |

JNIOR Serial Ports

The JNIOR Model 410, 412 and 412 each have two available serial ports. Each port providing at least a 3-wire RS-232 interface. A 3-wire connection contains only the Transmit (Tx), Receive (Rx) and Signal Ground (GND) circuits. This is the bare minimum for Duplex communication or interfaces utilizing software handshakes. The Rx line may be omitted if only sending data. Similarly the Tx might be omitted if only receiving data.

In addition to the 3-wire signals the AUX port supports optional hardware handshaking using the Request To send (RTS) and Clear To Send (CTS) signals. The Model 410 AUX port also provides a configuration for RS-422 and RS-485 communications.

While there are a number of parameters that must be properly configured in order to achieve functional and reliable communication, the biggest issue is (and has always been) proper cabling. If an RS-232 connection is not working and it is the first time the connection has been made, the connections are probably not correct.

Originally the RS-232 standard was created to support the connection of a modem. Before networking the modem was used to extend communications over standard telephone lines. Typically a computer (an IBM 360 for instance) would connect to a modem. At home a user would connect their terminal to another modem and establish a remote connection via dial-up. There are two types of equipment in this scenario: the computer stuff and the communications stuff (modems). The RS-232 standard defines two acronyms for this: DTE and DCE. These are used extensively to define connector types and signal definitions.

This is where the confusion begins. The acronym DTE refers to Data Terminal Equipment and in our example above this includes both the Computer and the Terminal (CRT or Teletype). That would be the stuff that you would be trying to connect together had you not needed the modems. The term DCE is often confused and is meant to refer to Data Circuit-Terminating Equipment or Data Communications Equipment. That being the modem in the above example. It does not stand for Data Computing Equipment which implies the computer. These terms are often confused and, perhaps, never really understood. As a result even the engineers who design the equipment (including myself) often employed the incorrect connectors, signal terminology and pin assignments. So let’s not use these designations.

 

JNIOR Serial Ports

The JNIOR has a COM port (labelled RS-232) and an AUX port (labelled AUX Serial). Both are DB-9F Female 9-pin D-sub connectors. The AUX port has 4 active signals and the COM port 2. The pin assignments are as follows:

2 >> RS232 TX / RS485 TX-
3 << RS232 RX / RS485 RX-
5    GND
7 << RS232 RTS / RS485 RX+
8 >> RS232 CTS / RS485 TX+

Here is how it shows on the schematic. Note that even the pin numbering on the the connector itself can be confused. The (>>) indicates an output. The JNIOR generates a voltage on this pin and it must be connected to an input at the other end. The (<<) indicates an input. This should be connected to an output at the other end. We will cover RS485 in a little bit.

You can see that we do not use DCD, DSR, DTR and RI. These are unconnected. The COM port follows the same assignments but ONLY pins 2, 3, and 5 are used.

Here is the source of additional confusion. The JNIOR transmits data on Pin 3 and therefore from the JNIOR’s point of view THAT is Transmit Data (TX or TxD). But when that signal reaches the other end (say your PC) it is incoming data or Receive Data (RX or RxD). That is because from the point of view at the PC it is data that would be received. So you connect RXD to TXD and visa versa.

Not everyone labels it that way. You will find an input pin labelled TxD. The thinking is that you would connect TxD to TxD. After all you do connect CTS to CTS as the signal is Clear To Send regardless as to who generated it and who is listening to it. The same goes for Request To Send (RTS).

It is not surprising that we sometimes have to grab a voltmeter to see if a pin is generating an RS232 voltage level (an output) or not (an input). Even that can be misleading when pull-up resistors are used. I used to have a couple of really sweet RS-232 break-out boxes. Those have gotten lost but were life savers back in the day. You know, nice colored LEDs showing outputs and jumper wires that you could use to test various cabling solutions before soldering the final cable.

JNIOR to PC Connection

Well today if you want to connect the JNIOR to your PC you will need a USB-To-Serial adapter. You would likely want to do that to gain access to the JANOS Console (command line interface) available over the COM port (115.2Kbaud, 8 data bits, 1 stop bit, no parity). The adapter will present you with a DB-9M Male connector identical to what you would have found on an older PC as a COM or AUX port connection. The connector (DTE) can be directly plugged into the JNIOR COM (or AUX) port (DCE).

Some USB-To-Serial adapters provide a length of cable and others are relatively short. If you need a longer cable then you either use a USB extension or an Male-To-Female Straight-Thru Serial Extension cable. The latter would need only be 3-wire unless your application optionally employed the hardware handshake. I will cover that a little later.

You would use this same approach to connect the JNIOR’s AUX port to a PC-based media server or other system that uses the standard PC serial ports. An application on the JNIOR can then send and receive data or commands to the remote server.

Connecting a Device to the JNIOR

If you plan to connect a barcode scanner or other device to the JNIOR then you might need a little help. You may need a 9-pin Gender Changer. There are two kinds: F-F and M-M. You may need the Male-To-Male (m-M) Gender Changer. This has pins on both sides and when plugged into the JNIOR it changes the connector from a Female DB-9F to the equivalent of a Male DB-9M. Unfortunately this does not alter the pin assignments and if the device was designed to be plugged into a PC then you will need a cross-over adapter or cable. The cross-over exchanges pins 2 and 3 (as well as 7 and 8). Remember that you want to always connect an output to an input. Sometimes this is called a Null Modem adapter, the name coming from the need to interconnect two DTE devices without modems.

Perhaps in hindsight it would seem that the JNIOR AUX port should have been DTE. In fact in the beginning we did not use a DB9 connector at all and provided screw terminals for the 5 signals since we would be required to connect to either DTE or DCE. The reality is that in Cinema (which was an early and big market for JNIORs) we connected often to media servers (which are essentially PCs) and the current DCE arrangement worked best for those customers. That stuck.

So as a result you end up with stuff like this.

Of course if you are handy with the soldering iron and get some solder-cup DB9 connectors and hoods from Digi-Key, you can clean this up nicely. They had hoped to solve all of this with USB but that has created other issues.

It didn’t help RS-232 that from the beginning no one fully understood how to document it. Some of us might remember the detailed signal diagrams explaining plus and minus 12V states, start and stop bits, and little endian order in the back of manuals. That level of detail was just adding to the confusion.

Here is a modern day failure. This is from a product received in 2017. At first glance you would think this is good documentation.

Here only the boldface signals are available or can be used. Perhaps only those should be shown. But beyond that picky item the important piece that is missing is any indication or what is an output and what is an input. You can naturally make your own assumptions. You might correctly assume that Received Data (RxD) is information generated (or output from) the remove connection and therefore an input at this connector. The TxD would then be an output. I mean you only have two choices here and chances of being correct are 50/50. If you are working a soldering iron though you won’t appreciate making the wrong guess.

It is not so obvious as to whether the CTS or RTS connection is an input or output. These signals are shown here but are they used? Are they required? Is there an option setting some place of which you should be aware?

So if you have the diagram for the other piece of equipment that you are connecting should you wire straight thru? Do you wire TxD to RxD and vice versa? If that ends up crossing over from pin 3 to pin 2 and vice versa should you also cross over RTS and CTS? Who knows. RS-232 failure.

My point though is that this nice little picture doesn’t eliminate the chance that your cabling or the cable you make might not work. And, if it doesn’t work you don’t have enough information to decide what to change. Come on man! You can do better.

By | On March 19, 2018 9:44 am | No Comments |

Standard Isolated Digital Input

Did you know that every JNIOR since the beginning of time has used the same isolated digital input design? It is not that this design is particularly special. It is more that a better one hasn’t been suggested or required.

Here it is from external connector to the RX63N processor pin (right to left).

The input is optically isolated by the device U12. That means that you can bring a signal from a distance and not have to worry about it being referenced to any local GND. You won’t create any ground loop. There is no common connection between signals (they all need not be referenced to GND). To activate the input then all you have to do is turn that LED on.

The diode D34 protects the isolator LED from high voltages. You can put 30V on this input and not risk LED damage. The extra voltage above 5V is dropped across the 910 Ohm 1 Watt resistor. The input is limited by that 1W power rating. The maximum voltage is 35VDC. And 1 Watt is a lot of heat so you probably want to limit the amount of time that the input sits at that voltage.

To deal with that limitation you could add a series resistance. The maximum voltage is 5V above the square root of the series resistance assuming 1W resistors. So if you want to sense the presence of a 120VAC signal you might insert a 20K series resistance. I will leave the Ohm’s Law exercise to you. Just make sure that you can dissipate the power.

The input can be considered to have about a 1200 Ohm input impedance. It is not a high-impedance input. Therefore any signal used to drive an input must be able to deliver current into a 1200 Ohm resistance and turn on the isolation LED.

The circuit after the isolator creates a 2 KHz low-pass filter. Basically we’ve specified that input signals should not exceed 2000 Hz. The reasoning behind this lies in the need to be kind to the processor. Each input transition generates a software interrupt and executes some code. This allows JANOS to know when the state of the input changes, perform some debounce, and log the event. If this happens too fast the system can be overwhelmed having to execute interrupt code back to back and not get anything else done. That’s not ideal. So the hardware prevents it.

The processor can handle faster signals to be sure. But not if several of the inputs are cranking like that. Besides, the JNIOR is not targeted into applications that process high speed signals.

Now the RED LED that you see when the input is active is driven by the output of that filter. In other words, if the after the filter the hardware thinks that the input is ON then it turns the LED on. So those LEDs are software driven. They illuminate when the input is high enough to activate regardless of how the input is configured internally.

I’ve been meaning to see if there is a more cost-effective and compact implementation for that filter. It was implements old-school with separate gates. Works though.

The input signal then interrupts the processor. In the Series 4 each separate input has its own interrupt channel. That was not the case in the Series 3 where we had some trouble insuring that all of the input channels were properly counted when triggering simultaneously. There is no issue in the Series 4. Each input can be configured.

This shows the input signal processing. In this case we go from left to right. The DIN input generates interrupts. It can be optionally inverted by configuration prior to the debounce logic. This is consistent with the Series 3. Logically though you might want to invert an input afterprocessing. That inversion can be performed by the Conditioning block which finalizes the input state for the system. This is an extension in the Series 4.

The debounce delay by default is set to 200 milliseconds. Basically when an input that has been in one state for a while changes the new state is recognized immediately. The debounce timer then is started. During the delay time additional transitions restart the debounce timer and those state changes are ignored. The reported state is then refreshed once the timer does expire. The trigger is rearmed at that point.

This debounce approach effectively stretches an input pulse until it has been stable for the delay period. So if you want to detect the presence of a 60 Hz AC signal then you need to set the debounce delay long enough to ignore the time when the AC signal does not drive the input. That would be at least 17 milliseconds.

Latching

Input Latching is optional. When not enabled the function is bypassed as indicated in the flow diagram. When enabled it can be configured to latch either the HIGH or LOW state. Once latched the input state will remain the same until the input is reset. This would allow you to catch and deal with a pulse or otherwise not lose track of the fact that some alarm condition had triggered.

The latching can be configured to time out. This will latch a pulse and allow it to reset itself after a period of time. You can use this to stretch a short pulse so logic downstream has the time to detect it and to deal with it.

Counting

Once the input has been debounced and optionally latched it will be counted. The counter can be configured to count a LOW to HIGH transition (0->1) or a HIGH to LOW transition (1->0). Each counter can be reset to 0 or set to any initial value. These can even be manually incremented by an application.

When counters are displayed they can be scaled and shown with unique units. A counter can trigger an alarm when it reaches predefined values. Alarms can send email notifications.

Metering

The Usage Meter totals the length of time that an input has been active. You can tally time for the HIGH state or for the LOW state depending on configuration. Usage meters can be reset to 0. This can be useful in monitoring the operating time of a piece of equipment. An alarm can be triggered when the usage meter reaches a configured amount of time. Alarms can send email notifications. This could be helpful as a reminder for the performance of preventive maintenance.

Logging

All input and output signal transitions are by default logged. The IOLOG command can be used to review I/O activity.

Conditioning

Finally the input state can be conditioned (Series 4 only). Here the input state can be optionally inverted or forced to a HIGH (1) or LOW (0) state. The forced states may be of use in debugging applications or disabling an input without having to physically disconnect it. A forced input is masked but continues to be counted and metered.

Alarming

Note that alarms are available for Counters, Metering, and Input State. Alarms can be configured through the Registry or DCP. These can send unique email notifications.

In summary…

A digital input seems like it is a simple thing with just a HIGH or LOW input state. There is however a lot more to it. We have seen here what effect the hardware has and how the input can be configured. All of this before the input state ever affects any application.

By | On November 22, 2017 9:37 am | No Comments |

JNIOR Connectors

The JNIOR Connector Kit contains 5 connectors. Four (4) are the 8-position female screw terminal types for I/O connections and one (1) a 4-position connector of the same style for the power connection. The latter will also be found on power supplies that are obtained from INTEG. here are the part numbers.

They look like this. The others having 8 positions of course.

These are SINGLE ROW FEMALE TERMINAL BLOCK PLUG 0.200″ 5.08MM PITCH. Color is irrelevant although INTEG tries to supply BLACK for digital signals and power, and GREEN for analog (external modules).

There are alternatives to these connectors that you can source separately. INTEG does not stock an alternative although arrangements can be made upon request.

Connectors are generally an expensive part of the product. These two-part connectors add value to the JNIOR.

Some wiring hints…

If multi-strand cables are used it is recommended that either the stripped end of the wire be properly tinned or some form of crimp pin be employed. If neither is convenient then insure that the stripped wire is tightly and cleanly twisted and clamped securely by the connector. Cables should have sufficient slack so as to not stress the connection as connectors are inserted or removed. Ty-wrap cables for a single connector together within 3″ of the connector to provide strength in numbers.

If solid cable is used then it is important that cables have sufficient slack so as to not bend the cable at the connector when the connector is inserted or removed. Ty-wrap cables for a single connector together for added protection.

Screw terminals should be hand-tightened strongly. Periodically check screws and tighten as necessary. Repeated changes in temperature can over time loosen screws.

Clamping more than one cable at a connector position is not recommended. In this case the clamping mechanism will grab the largest diameter wire more strongly creating an intermittent and loose connection with the other. If you must chain wiring in this fashion either tin wires together or tightly and cleanly twist them before clamping. Carefully wiggle both wires separately to insure that both have been securely captured.

When stripping wire use the proper tool with the proper wire gauge setting. Be careful not to cut into the copper conductor. This is highly likely if using a knife to remove the insulator. This can completely cut outer strands of multi-stranded cables reducing their current carrying capacity and increasing the possibility of a poor connection when clamped. Over time as cables are flexed cables that are improperly stripped will tend to break where the insulator has been cut.

If your wiring reaches the JNIOR from above you may consider a connector style where the cables leave the connector at 90 degree angles. For example you can source connectors like this one.

This is Pheonix part nubmer 1836901 and these are available from other manufacturers.

There are screwless connectors. These use spring force to achieve clamping and have the advantage of not loosening over time. There are different approaches. Here is one example.

If strain relief is an issue it is best to secure the cabling to the connector. An arrangement like this can be helpful. This eliminates the flex at the cable end where wires may break or loosen.

Now if you are willing to carry another crimping tool you can take a different approach. This would be much more appropriate when the JNIOR is installed within another product or rack mounting. Here you by just the housing and crimp a pin on each wire which is then inserted.

Here there is no question of loosening and strain relief is built-in. That assumes you are proficient at crimping. This is Pheonix 1808832 and I will attach the data sheet as well.

1808832

If you are using the JNIOR PCB without the housing as part of your product and are will to purchase in quantities of say 100 and allow for a standard lead time we can accommodate any connector arrangement. The PCB holes are on 0.200″ (5.08mm) centers.

Depending on the commitment we can also create a custom PCB to meet your specific needs. This is not as expensive as you might think. Cost does depend on quantity. Call us. We are willing to work with you.

There is no cost in asking.

By | On November 10, 2017 10:47 am | No Comments |

Dry Contact Relays

Probably the most basic function that the JNIOR can perform is to close and open one of its relays. This is one of the ways the JNIOR controls the world around it. The Model 410 has 8 relays; The Model 412 has 12 relays; And, the Model 414 has just 4 relays. The number of inputs varies as 8, 4 and 12 respectively.

These are small signal relays. Early production JNIORs (with Omron relays) are limited to 1A. We currently use relays that can handle 2A. Voltages as high as 120VAC or more may be used. The limiting factor though is the current and the inductance of the load. If you use one of the relay outputs to drive something like a larger relay’s coil you should make sure there is a flywheel diode for Back EMF Suppression in the circuit. Otherwise the spark that would occur across the contains will seriously limit the life of the relay. A MOV device would be even better.

The Power 4ROUT external module that we have available uses 10A relays and has built-in MOV devices across each contact pair. The part is Panasonic ERZ-V07D431 VARISTOR 430V 1.75KA DISC 7MM. These can obtained from DigiKey among other places. If you are driving an inductive load you can purchase these or similar devices and place one across the relay outputs to extend the relay life.

ERZ-V07D431 VARISTOR

There are a number of good pages on the Internet that address this concern. You can search on “Back EMF Suppression” for more information.

Each Series 4 has at least two relays that can be modified by internal jumper to function Normally Closed (NC). The Model 412 has 4 that can be so configured.

Right out of the box you can control the relays. Once you have connected the JNIOR to your network and set the IP addressing you can point your browser at the unit and open the DCP. Log in as the administrator. The default username is ‘jnior’ and the password is ‘jnior’.

WebUI Default Page

Here you can click on a “Toggle” button to turn on (close) and off (open) each relay. In the configuration section you can change the control to “Pulse” as I have done here for Relay Output 8. You can define the pulse duration in milliseconds. In fact, through configuration settings you can alter many aspects of this screen including the labels. The display can then reflect your application.

A “guest” login will only be able to view the status. The control buttons are not displayed.

So if you allow access to the JNIOR through your router you can control relays from anywhere in the world. It is highly recommended of course that you change the administrator’s password. I would also disable the “admin”, “user” and “guest” accounts if you do not need them. Use the USERS command in the Command Line Console to see the status of accounts. If you open your JNIOR up to the world you need to make sure that it is secure.

Command Line Relay Control

You can control the relays from the Command Line Console using the JRMON command. The Command Line Console is available as a tab in the DCP (see image in prior post), through a Telnet (Port 23) connection, or through connection to the Serial RS-232 (COM) port at the bottom next to the LAN port on the JNIOR.

The JRMON command will start an ASCII based real-time I/O status and command console. If you wish to control you need to use the JRMON -C option to enable command input. Here a “C1” closes Relay Output 1, “O1” opens that relay, and “Q” exits the mode.

JRMON Control

The 0’s and 1’s reflect the real-time status of inputs and outputs. In this case we have a Model 410 with 8 inputs (all off) and 8 relays (all off to start). Here additional relays will appear if you have a Model 412 or add 1 or more external 4ROUT modules. The number of inputs also follows with model with up to 12 inputs on a Model 414.

You can execute a JRMON -X command at the Command Line and not invoke the real-time display. The following command closes Relay Output 2 and opens Relay Output 1.

jrmon -x c2o1

The JRMON is useful in debugging Digital I/O using the serial RS-232 (COM) port and through a Telnet connection. If you have network access though perhaps the DCP is more convenient as the Graphical User Interface is nicer. You would likely not need to use the JRMON command through the DCP Console tab.

JNIOR Protocol

The JNIOR Protocol is deprecated and not recommended for new development. It is still supported however. For the Series 3 this was the protocol to use for remotely controlling the JNIOR. It is a binary protocol and very efficient. Experienced programmers can develop drivers to handle the JNIOR Protocol. INTEG supplies an SDK and API allowing PC applications to utilize the JNIOR Protocol. The Series 4 provides a more modern approach through a built-in Websockets interface. It’s use is preferred.

I have attached the current JNIOR Protocol specification. Relays can be controlled through this protocol using the Command Message (Message Type 10). The status of the JNIOR is obtained through the Monitor Message (Message Type 1). The JNIOR Protocol is not strictly Master-Slave. While there are commands and responses, there are unsolicited messages. The Monitor Message is supplied by exception whenever I/O status changes. You do not need to poll for status as you would with MODBUS for instance. You would just wait and consume Monitor Messages when supplied. The Websockets interface is similar.

JNIOR Protocol

Websockets Interface

With the Series 3 the configuration pages reached using the browser were required to execute Java Applets. The applet is the only way of making the JNIOR Protocol connection (Port 9200) for web use. Today both the applet and the JNIOR binary protocol are outdated.

The Series 4 Dynamic Configuration Pages (DCP) are also accessed through the browser. These use modern Dynamic HTML and JavaScript. This communicates with the JNIOR through a Websockets connection which is supported by all browsers over the same HTTP or HTTPS connections. The Series 4 built-in Websockets interface uses JSON messaging and provides for a wider set of capabilities. The DCP can manage files on the JNIOR, offer Command Line Console access, and monitor real-time Syslog status. There is much more. A PC Application can make a Websockets connection as well.

Both the Websockets Interface and the JNIOR Protocol can be used to remotely control relay outputs and maintain status of JNIOR I/O.

The current Websockets documentation is a Wiki in our Redmine system at INTEG. I have generated a PDF copy of that document and attached it here. We will help you make use of this protocol.

Builtin_Websocket_Access

Program Control

There is one more way to control relays. That is through an application program running on the JNIOR. Application programs are written in Java and can be generated by Netbeans or any Java IDE and compiler. The Series 4 operating system (JANOS) can execute Java JAR files directly. You write your program using the JNIOR runtime libraries, load it onto the JNIOR and execute it. Applications can be set to start at boot.

You can do just about anything with an application program on the JNIOR. Manipulating the JNIOR I/O is obviously one of the most important.

For example, the following program when executed closes Relay Output 1.

import com.integpg.system.JANOS;

public class Main {
  public static void main(String[] args) throws Exception {
    JANOS.setOutputRelay(0, true);
  }
}

Relay Test Program

In this case I created a Project in Netbeans. I referenced the JanosClasses.jar runtime libraries (available in the JNIOR’s /etc folder). The program must be built to run in the JNIOR environment. It’s close to but not the same as a standard Java Runtime environment for the PC. It has additional classes like the JANOS class that provide for JNIOR functionality.

The program is compiled and the JAR copied from the dist folder into the /flash folder on the JNIOR. I just drag and dropped it into the proper folder using the Folders tab of the DCP.

Then from the command line just type the program name “jtest” to execute. It takes a second for the JVM to load and start the program. The relay then closes.

By the way, I like to include the “throws Exception” or “throws Throwable” in my main method when I am first developing a program. Later I will remove it and then be forced by the compiler to place necessary try-catch clauses to get error handling as it needs to be. Uncaught exceptions are nicely reported by the JNIOR.

Other Control Methods

There are still other ways to control JNIOR I/O. For one you can enable the MODBUS protocol. The JNIOR can be configured as either a MODBUS Server or MODBUS Client. Addressing is defined for the JNIOR I/O. There are a number of standard applications that INTEG supplies. The CINEMA application for instance allows you to define macros that are triggered by certain events and those can manipulate the I/O.

Did I miss any? Maybe you know of another?

By | On October 31, 2017 3:12 pm | No Comments |