Does any one at CSI know if the number of characters / lines in a generic modem script has increased between LoggerNet 3.4.1 and LoggerNet 4.0? Alternately, a better way to do what I've shown below?
I ask because we use Freewave FGR (and CSI RF450s) in point to point mode. With the script limits of 3.4.1 I can call a number from the radio call book, "ATDT1", but not call something outside the call book like "ATD1234567" or "ATXC1ATD2345678".
Here is a short example script for calling a site via the Freewave call book but last time I tried there were problems extending this method to several more Transmit/Error sequences as would be required for a longer dial script:
T "A" E "Err01"
L "Err01"
T "T" E "Err02"
L "Err02"
T "D" E "Err03"
L "Err03"
T "T" E "Err04"
L "Err04"
T "4" E "Err05"
L "Err05"
R "OK"1000
R "CONNECT"4500
Thanks
--Bob
The LoggerNet server imposes no specific limits on the lengths of the generic modem scripts and, to the best of my knowledge, the SetUpScreen client does not do this either. However, I did notice that the client fails to show scroll bars for the script controls but this is a cosmetic thing that should not effect what gets written to the settings.
That said, I'm not sure that you need all that in your script. You could do as follows:
E "retry"
L "retry"
T "ATD1234567"
R "OK" 1000
R "CONNECT" 4500
I'm not sure why you have all the transmit/error sequences present. Since the "T" command does not wait for any response, the only error that can result is that the characters can not be written. Because of this, most of your error handlers will have little, if no effect.
Thanks, my mistake. It may sound strange but I have had the script you pasted in not work depending on the version of LoggerNet, hence the hack... playing a bit more with this over the last day+, is there a difference in how generic modems are treated if the root is COM1 vs. an IP Port?
I seem to have no problem for generic modem scripts accessed through an NL100 as root in setup but attached to a COM port it's a completely different story:
Failure: 8/5/2010 12:17:48.578
transaction failure","unreachable destination","Get Logger Program Status
Failure: 8/5/2010 12:17:48.578
transaction failure","unreachable destination","check/set clock
Failure: 8/5/2010 12:17:58.593
transaction failure","unreachable destination","Get Logger Program Status
Failure: 8/5/2010 12:17:58.593
transaction failure","unreachable destination","check/set clock
Failure: 8/5/2010 12:01:30.500
Serial open failed","5","Access is denied.
Failure: 8/5/2010 12:01:31.500
Open failed
Failure: 8/5/2010 12:01:40.515
Serial open failed","5","Access is denied.","10035","A non-blocking socket operation could not be completed immediately.
Failure: 8/5/2010 12:01:41.515
Open failed
Looking at the I/O log for COM1... it's empty... Same result with two different computers.
This setup works:
IP Port -> Generic -> PakBusPort -> CR1000
This doesn't:
COM Port -> Generic -> PakBusPort -> CR1000
Generally with serial ports, the reason for the "access denied" message is because you are fighting with another process or "ComPort" device in loggernet for access to the same serial port resource. If you have set up each generic modem to communicate on a separate "ComPort" device in LoggerNet's network map but those "ComPort" devices are all using the same serial port, this may explain what you describe above. Alternatively, there may be a separate process (Palm synchronisation software is infamous for this) that is using your serial port.
Similarly, with the NL100 configured as a serial server, it will only allow one connection to be made at a time. Given this, it looks like you are fighting some other process there as well.
I agree it certainly sounds like a comm port trouble but my money is still on an internal LoggerNet issue, something in the way the program handles generic modems perhaps when attached to the COM root rather than IP root? I have this same behavior on two different computers both with simple hardware configurations, one's a toughbook in the default configuration and the other is a desktop. MS Active-sync & Palm synchronization programs etc. aren't installed on either computer. If you don't mind, let me step you through the configuration and what doesn't work and then what does work, here are a few screenshots to illustrate:
From the Setup window, the hardware tab of the com port:
(Showing: COM1, Communication Enabled, Call-back Disabled)
http://werc.engr.uaf.edu/~bob/gen_modem_probs/setup_COMPort_Overview_1.GIF
From the Setup window, the hardware tab of the generic modem:
(Showing: Communication Enabled, 9600 Baud)
http://werc.engr.uaf.edu/~bob/gen_modem_probs/setup_generic_hardware_tab.gif
From the Setup window, the modem tab of the generic modem:
(Showing: a working modem script)
http://werc.engr.uaf.edu/~bob/gen_modem_probs/setup_generic_modem_tab.GIF
From the Setup window, the hardware tab for the PakBus Port:
(Showing: Communication Enabled, 9600 Baud, PakBus Port Always Open Disabled)
http://werc.engr.uaf.edu/~bob/gen_modem_probs/setup_pakbus_hardware_tab.GIF
From the Setup window, the hardware tab for the CR1000:
(Showing: Communication Enabled, Call-Back Disabled, PakBus Address)
http://werc.engr.uaf.edu/~bob/gen_modem_probs/setup_CR1000_comtest_hardware_tab.GIF
A screenshot of the whole of LoggerNet:
Stepping through all the open windows:
1) The Setup window showing only one device attached to the COM port
2) The LogTool Showing the Communication errors
3) The Connect Screen & related Comm Failure window
4) A blank Lowlevel I/O window
5) The Status Monitor showing the 99.99% average error rate w/ the Generic Modem
6) More generally, you can see there aren't any other competing programs in the task bar and no syncing programs in the system tray
http://werc.engr.uaf.edu/~bob/gen_modem_probs/Loggernet_whole_package.GIF
Next, a connection to the logger through DevConfig with local character echo on (so the ATDT7 is visible):
http://werc.engr.uaf.edu/~bob/gen_modem_probs/DevConfig_Successful_Connection_With_Local_Char_Echo.GIF
Finally, I change the base radio from Mode 6 (Slave / Master Switchable) to Mode 0 (Point to Point Master) so the radios are transparent to LoggerNet and then in LoggerNet Setup move the CR1000 from being a child of the Generic Modem to connected directly to the COM Port... Here is a good connection to the logger (screen shot is similar to the previous one showing setup layout, connect window and log windows):
http://werc.engr.uaf.edu/~bob/gen_modem_probs/Loggernet_whole_package_differnet_radio_mode.gif
Any thoughts or does anything jump out? thanks for taking the time to check it out, too.
I just this afternoon tried replicating all of this with LoggerNet 4.0 on a new Toughbook and the result is the same.
Here's how to duplicate the setup in its entirety:
1) As far as I can tell you'll need a proper Freewave FGR series radio for the master. I was trying to do all of this with RF450s this afternoon and couldn't get a master-slave connection with Mode 6 when using an RF450 as the master.
2) Connect the FGR radio using a DB9 serial cable to the serial port on your computer.
3) Start up DevConfig, choose Unknown Device and 19200 Baud
4) Toggle the setup button on the back of the radio.
5) Choose menu item '0': Set operation mode.
6) for the master select '6': Slave/Master Switchable and then hit 'Esc' to get back to the main menu.
7) At the main menu select '2': Edit Call book to add the serial number for the slave radio, in my case 882-5337. In the examples earlier in this thread this address is in entry 7.
8) Hit 'Esc' a couple times and set up with this radio is done (I'm presuming here you know what baud rate it's operating at... if not, check it out at menu item 1... also assuming the radio transmission parameters are already set correctly...)
9) disconnect this radio from the serial port and plug in the RS232 port on the RF450, keep DevConfig connected to the unknown device at 19200 Baud.
10) Click the 'Setup' button on the RF450.
11) from the menu that appears choose '2': Invoke Freewave Setup
12) Hit '0' to set the operation mode.
13) from this menu choose '1' or '4' to make this radio a point to point slave (1) or slave/repeater (4). Then hit 'Esc' to get back to the main menu.
14) From the main menu choose '2' to Edit the Callbook.
15) Select entry '0' and for me, the master radio is 916-4340
16) Hit 'Esc' a couple times to exit this menu and get kicked back to the RF450 menu.
17) I don't think it actually matters but choose '5' or '9' from the RF450 menu to exit the configuration.
Now the radios are setup. Connect a logger to the slave radio... in my case it's via the CSI/O port and then connect the master radio to the computer you're using.
At this point I have the master set up at 9600 baud and if I connect with DevConfig and type 'ATDT7' I will have flash on the screen 'OK' followed by 'CONNECT'. Hit 'Enter' a few more times and I receive the 'CR1000>' prompt... Good Connection.
So, using that hardware set up (I'm presuming I didn't overlook something here on the outline) the computer should connect up from a terminal window to the 'remote' logger.
Within Loggernet, using these same hardware components (as also shown in those screenshots above):
Setup Window -> Add Root -> Add COM port -> Attach a Generic Modem to it -> Attach a PakBusPort to the generic modem -> Attach a CR1000 to the PakBusPort
Set the modem script to 'T "ATDT7" R "CONNECT"4500 '
That is the nonworking combo. However, if you have an NL100 handy setup as a serial server and do the following within LoggerNet with the same additional hardware connected to the NL100:
Setup Window -> Add Root -> Add IP port -> Attach a Generic Modem to it -> Attach a PakBusPort to the generic modem -> Attach a CR1000 to the PakBusPort
Set the modem script to 'T "ATDT7" R "CONNECT"4500 '
This combination connects correctly (presuming you use a serial cable with pin __ disabled between the master radio and the NL100).
With all that said, it's not the end of the world that this doesn't work from the RS232 port, it would just be nice to test locally before deploying. It would also be nice to be at a remote repeater and test connectivity from LoggerNet if there are communications problems. I think that's pretty much it. thanks,
--Bob
