Announcement

**Bruce Cloutier** · 04-28-2022, 12:17 PM

Here's another helpful command. This is useful in verifying any of the network addresses that you have in IP settings.

Code:

bruce_dev /> ping -v
  LAN connection: active (100 Mbps)
         Gateway: Reply from 10.0.0.1 (1ms)
     Primary DNS: Reply from 10.0.0.1 (1ms)
   Secondary DNS: not available
     Mail Server: not available
      NTP Server: Reply from 192.48.105.15 (42ms)
   Syslog Server: not available
 www.integpg.com: Reply from 50.197.34.74 (3ms)

bruce_dev />

If an address/domain is configured in one of these settings that address is pinged (one ping only - Hunt for Red October reference) to verify access to it. We include our website address to check Internet access.

(Hmm... It is when I paste that the spaces are dropped from the pasted text.)

**Bruce Cloutier** · 05-20-2022, 08:27 AM

If you already have a JNIOR you can have it also monitor some temperature and with a simple application (that we can toss you) you can control a relay to power an exhaust fan for instance. I know its crazy but I actually have a 12V cooler being controlled by a JNIOR with such a simple program. Um... keeping my beer nice and cool but not frozen. For some reason I have a JNIOR or two laying around. Good for testing/experimentation. The beer that is. I can document that. Ah.. the application I mean.

Many of you are already using our environment/temperature sensor to monitor the booth. You may have noticed that unlike all of the relay and analog expansion modules the temperature sensors don't support the daisy chaining and must be placed last in the chain. So here's the tip. You can use a simple 6p6c modular 3-female splitter (available from Amazon) to accommodate more than one temperature sensor.

6p6c_splitter.png
Now you are not really supposed to split off legs off the underlying network. So there is the chance that this won't work reliably say if you are in a very noisy environment or wire lengths are excessive. But it works generally. Of course, with more that one temperature source you will need to make sure that each application addresses the right sensor.

I had a geothermal heat pump installation at my prior residence. We had a JNIOR monitoring it and there were 5 temperature sensors placed at various points in the system using splitters like this. We weren't particularly happy with the system efficiency. It uses 5 vertical wells for heat exchange in a closed loop system. I think the geology didn't support the best heat exchange/storage. So learning from that we will do something different should we upgrade the current home.

**Harold Hallikainen** · 05-20-2022, 11:58 AM

Is that an RS485 network? I had switchable terminations in RS485 devices (like the JSD-100 remote volume control) so you could loop through each device and just terminate at the end of the bus.

On beer required for testing, I once toured a diatomaceous earth mine. The lab there had a large quantity of beer for testing since breweries use diatomaceous earth for filtering. It was necessary, of course, to test the product in its actual application.

Harold

**Bruce Cloutier** · 05-20-2022, 01:47 PM

It is actually close to the Dallas/Maxim 1-wire. But with any of these networks there are signal reflections that the termination is meant to reduce. The theory requires the devices along the way to tap the network very close to the main wire so as to not generate issues of their own. Transmission line theory you know. So using a splitter to Y the network is not strictly proper. It works. Probably because we are running this net at 9,600 baud.

That's another "tip" for ya. The temperature sensor that we supply is in fact a 1-wire product as is the Humidity/temperature sensor. The JNIOR can interact with those. And if you want to use a custom device out there the Java library contains a SensorPort class with the ability to work with unknown devices. The expansion modules are not exactly 1-wire and they don't work with standard 1-wire systems. But they're close.

Here are the connections. Note that DCK and VUR are Reserved and not used with the Series 4 JNIOR. VCC is 5V capable of supplying 250ma (ergo the limit on the number of 4ROUT relay modules as coils take current). Don't hold me to that current rating. Its from memory.

Sensor_net.png

You can see how you might employ an external 5V supply to increase the number of 4ROUT modules, you know, for more relays if that is your thing.

I should write up an application note for the beer thing.

**Fraser Falconer** · 05-20-2022, 08:21 PM

Hi Bruce,
You can advise me and maybe help others at the same time. Is there a way to monitor in real time ( for the purpose of system fault finding) Jnior contact closure, either by the support tool or web interface?
I recently had a situation where The dimmer was missing the lights down command. The vendor of the dimmer said that the Cinema system was the issue, but by means of the GDC playback logs and Jnior logs I could prove that it was actually external, post the Jnior. I just thought as a fault finding tool, If I could be connected to the Jnior in real time and monitor the contact closure during playback to verify operation, especially when working remotely.

Cheers Fraser

Attached Files

Jnior Log edit.png (24.0 KB, 184 views)

**Bruce Cloutier** · 05-21-2022, 06:04 AM

Fraser, yes there are real time ways to monitor the I/O. Even with that you'll often have to get creative to catch a glimpse of what ever issue you may be having. We actually go overboard with logging and there is even an application now that you can set to run (JBakup) that will archive logs for posterity.

First you can open the WebUI and the default tab displays input and output status real time. So you can observe the relay change there, well, assuming your aren't set to pulse for a small fraction of a second.

From the command line interface (CLI) there are a couple of options. You can reach the CLI through the WebUI on the Console tab. You can Telnet to the JNIOR. We like PuTTY for this and have our own utilities for Telnet (since we do have a non-standard secure encryption option). There is Telnet access built into the Support Tool. And, you can access the CLI through the RS-232 (COM) port next to the LAN connection at the bottom of the JNIOR (115200/8/1/N).

iolog

Type HELP IOLOG for information on this command. If you are running JANOS v2 there is a wealth of (searchable) information now available with HELP. The -L option to HELP will display the legacy help text as it would be with JANOS v1. All case-insensitive.

You are aware of this since you have included jniorio.log in your sequence of events.

The IOLOG keeps a rolling record of I/O. By default it outputs this to a file but you can output to the console (stdout) using the -O option. Okay, so this isn't real time though. My development unit doesn't actually do much I/O and so you can see that I have I/O logged back to March.

Code:

bruce_dev /> iolog -o
03/25/22 05:58:20.629, DIN ---- 0000 0000, RLY ---- ---- 0000 0010
03/25/22 05:58:20.863, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
03/25/22 06:00:04.741, DIN ---- 0000 0000, RLY ---- ---- 0000 0001
03/25/22 06:00:04.941, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
03/25/22 06:04:35.587, DIN ---- 0000 0000, RLY ---- ---- 0000 0001
03/25/22 06:04:35.787, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
03/25/22 06:10:30.794, DIN ---- 0000 0000, RLY ---- ---- 0000 0001
03/25/22 06:10:30.994, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
03/25/22 06:11:00.264, DIN ---- 0000 0000, RLY ---- ---- 0000 0001
03/25/22 06:11:00.464, DIN ---- 0000 0000, RLY ---- ---- 0000 0000
03/25/22 06:13:12.237, DIN ---- 0000 0000, RLY ---- ---- 0000 0001
03/25/22 06:13:12.437, DIN ---- 0000 0000, RLY ---- ---- 0000 0000

IOLOG also provides access to the transmissions through the AUX serial port and even over the Sensor Port (expansion bus). The latter is quite cryptic however.

jrmon

Now JRMON is one of JNIOR's earliest real time diagnostic tools. Use HELP JRMON for more information.

Since you are monitoring you can simply start JRMON from the command line. It will display inputs and outputs with 0/1 state information. A 'twirly' at the left spins with each update. Any key breaks you out of it.

Running JRMON -C provides for interactive control. So you can for instance close relay 1 by entering 'c1' followed by Enter. That syntax might look familiar to those of you sending serial commands to the JNIOR. In this mode the command 'q' is needed to exit (for [Q]uit).

But for monitoring purposes if you just hit Enter the monitor freezes the current line and moves to the next. this might be useful if you see something change and want to take a minute to understand what you are seeing before it disappears.

Code:

bruce_dev /> jrmon -c

JNIOR I/O Monitor

  [C]lose NNN, [L]ist Counters, [O]pen NNN, [P]ulse
  [Q]uit, [R]eset, [S]et Counters NNN, [U]sage
  NNN - list of 1-8 input/relay selection
  +N - list of 9-16 input/relay selection
  '=' to specify parameter (pulse duration in msec, counts)

   12--DINn---1 16----RLYn-----1 Default pulse = 100 msec
-  ----00000000 --------00000000 >
-  ----00000000 --------00000000 >
|  ----00000000 --------00000000 > q

bruce_dev />

Unfortunately, for some unknown reason, when I paste in the editor here it removes and compresses spacing. So output that I am showing might look better on the JNIOR itself than it does here. I try to add critical spacing back in. Its a pain.

The above shows that there is nothing happening on my JNIOR.

Ideally, it would be nice to have feedback with any server command that it was successful. So if the JNIOR were to be able to monitor the status of the dimmer and log that you would have the complete story. In that case too you could program the JNIOR to alert you (email or other) when something unexpected happens. In some cases this is doable.

Maybe in your case you can just manually toggle the relay to verify that the dimmer is responding?

The more complex we make all of this stuff the more likely something odd can happen. This is the "ghost in the machine" so to speak.

**Bruce Cloutier** · 05-21-2022, 06:47 AM

I should mention that just because the JNIOR indicates that a relay closed doesn't mean that there isn't a hardware problem still.

The closed indications in the monitoring tools mentioned above ONLY indicate that the JNIOR has commanded the relay to close. With the Series 4 the Relay LED is actually wired through a set of relay contacts. This was not the case with Series 3. So if the Relay LED comes on that means that the relay has been commanded to close and the coil has energized closing that one set set of contacts.

The other set of contacts are wired to the connector. Relay contacts can easily be damaged by high currents and voltages. Even when carefully and properly wired to within specifications a set of relay contacts can degrade. In particular if the contacts control an inductive circuit. You know if you tap the wires together and see a spark when they are separated then that circuit has considerable inductance (like another relay coil). That spark will happen once wired at the relay contacts and that will eventually damage them.

We have JNIORS running doors on people movers in airports. The customer was replacing the relays a little too often they thought (once is too often in my book). We suggested that they place a diode across the connector contacts (this provides a path for the current that otherwise would force its way across the gap spectacularly). Their problem went away. Well, as far a we know.

There can also be a rush of high current when the wires are first connected and that is a concern as well. This can be reduced with a small resistor in series with the connection. Relays are not as simple as you think... sometimes.

So testing the relay by manually closing it when you have a problem like Fraser's is not a bad thing to do.

You can disconnect the dimmer and use a voltmeter set to read Ohms. When the relay is open there should be infinite resistance. When it is closed there should be just a small fraction of an Ohm.

You can also have problems with contact bounce. If a relay pulse toggles the state of the connected equipment and it bounces you might be turning it OFF and then ON and then OFF and then ON again. The result might end up being random. This might be an issue if the connected device is 'edge triggered'. This is a bit harder to deal with. Remember oscilloscopes? My first was a HeathKit.

Something to live by... "Nothing is Easy."

**Harold Hallikainen** · 05-21-2022, 12:26 PM

Good ideas on relay contacts. Another possible issue is that the current is too low ("dry switching"). Are the relays rated for dry switching? When I used relays for dry switching, I used ones with bifurcated gold crosspoint contacts. But these are not good for handling heavier load currents. I wonder what the current on the dimmer control input is. Problems with low contact current usually show up as intermittent operation.

Harold

**Bruce Cloutier** · 05-22-2022, 09:24 AM

I should further note that the internal signal relays in a JNIOR are not protected. By default the normally open (NO) contacts are presented at the connector with no other circuit components associated. Note that on each JNIOR inside there are jumpers so at least 2 of the relays can be switched to present the normally closed (NC) contacts.

There are no protection components included as we did not know what type of signals will be switched. We didn't want to assume that this would not affect somebody's application. You can argue that decision. We could take that into consideration for Series 5.

The Power 4ROUT expansion modules however include a varistor (Panasonic ERZ-V07D431) across each of the exposed contacts (both NO and NC are available). This ZNR surge absorber is rated at 430V 1.75kA and provides some protection. Still if you are switching serious loads you should consider some form of additional external protection.

If you are switching high voltage house lights or anything serious I strongly suggest using a code-compliant contactor and controlling that with a 4ROUT relay output. Please do not try to switch 230VAC 20A+ circuits with the module. Um... the results can be spectacular. I have pictures.

**Steve Guttag** · 05-22-2022, 02:19 PM

I don't think the relays really need the protection. So long as the voltage/current ratings are clearly stated, it is up to the installer to not overload the relay. I agree with Harold, when it comes to dry-contact relays. If they are low-current low-voltage (48V or less), then gold-flash bifurcated relays are best as the currents can be extremely low and higher current contacts may yield false lows. Conversely, high-current relays shouldn't need to to consider such lower current control as there is a compromise between the current carrying capabilities and the contact material used.

**Bruce Cloutier** · 05-27-2022, 09:59 AM

Here's a tip...

The JNIOR keeps a number of LOG files. Usually they are of no use but when you get a sense that some automation didn't quite do what you thought it should, some record of the past is invaluable. In addition to log files, the IOLOG function keeps a record of past I/O state changes and a serial data transmission log for the AUX and Sensor Ports.

For the Series 4 JNIOR what you probably didn't know is that the network side keeps an ongoing capture of network traffic accessible through the NETSTAT command. This is like always running Wireshark. The NETSTAT -C command (NETSTAT with option -C) generates a capture file in the /temp folder. You can download this file to your PC and if you have Wireshark installed you can open the capture right up. If there is a communications issue you already have the capturing active. You don't need to run Wireshark and try to recreate the situation.

One caveat with this capture is that if you access the JNIOR using the WebUI the capture is flooded with HTTP port 80/443 traffic. Since the capture is limited in size (a registry key can enlarge it) it represents a limited time and your access to the WebUI can cause the loss of the event that you are most interested in. You can set some filtering and this leads to the real tip here.

The NETSTAT -F command establishes a network capture filter on the incoming side. With JANOS v2 you can use HELP FILTER for more information or search FILTER through the Help System in the WebUI. This filter can be set through the WebUI, directly by Registry key or by issuing a command like the one that follows.

Code:

netstat -f !(http || https)

This command (case doesn't matter) can eliminate the WebUI capture and leave the JNIOR Protocol or MODBUS communications in the capture for debugging and analysis.

You can also employ a filter in extracting the capture using the NETSTAT -C command with a filter specification. So if you are capturing everything or have already limited your capture but still are only interested in MODBUS port 502 you can do:

Code:

netstat -c 502

The will generate a capture file containing any packet exchanged with port 502 if there are any.

But the tip... You might set the incoming filter as above so when you later want to debug... your access doesn't destroy the evidence.

By the way, when you take a snapshot with the Support Tool these logs and captures are included.

**Mark Gulbrandsen** · 05-27-2022, 11:34 AM

Originally posted by Steve Guttag View Post

I don't think the relays really need the protection. So long as the voltage/current ratings are clearly stated, it is up to the installer to not overload the relay. I agree with Harold, when it comes to dry-contact relays. If they are low-current low-voltage (48V or less), then gold-flash bifurcated relays are best as the currents can be extremely low and higher current contacts may yield false lows. Conversely, high-current relays shouldn't need to to consider such lower current control as there is a compromise between the current carrying capabilities and the contact material used.

I would certainly want spark suppression on any relay that's handling over about 40 volts. It will make the crappy contacts of today last much longer. I would also like to see more use of solid state relays instead of the crap relays that are out there...

**Fraser Falconer** · 05-27-2022, 07:30 PM

Hi Guys,
Sorry for slow reply, The dimmer in question has Extra Low Voltage control. It's a 5v pull down to ground at 2mA. The Dimmer has been removed and replaced by the manufacturer and extensively tested. (no fault found) So we'll see how the new dimmer performs. Could be induced noise on the control line causing the issue, since everything tests alright and the fact it is intermittent. Thank you for all the useful information. Yes I am in the camp of not running relays at their rated current, as allowance needs to be made for in-rush current which is generally highly inductive, which de-rates your relay further.

Cheers Fraser

**Harold Hallikainen** · 05-27-2022, 11:01 PM

2 mA is pretty low for a relay contact. See https://en.wikipedia.org/wiki/Wetting_current . A small capacitor (10 to 100 nF) across the contacts would provide a short high current pulse when the contacts close burning through high resistance film.

Harold

Announcement

JNIOR Tips

JNIOR Tips

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment