Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - garysdickinson

Pages: 1 2 [3] 4 5
31
Technical support / FileZilla 3.11.0.2 and Fx/FMD PLCs
« on: July 06, 2015, 01:55:06 PM »
I may be losing my mind, but I can't get FileZilla 3.11.0.2 to work with the Fx and FMD PLCs.

I've had older FileZilla versions work, but now when FilleZilla sends the "LIST" command to the PLC's FTP server, there is no response from the PLC and the command times out.

I can "talk" to the PLC using Windows command-line version of FTP. This works fine to send/receive files and list out the files on the PLC. So I know that the problem is not with the PLCs nor my marginal understanding of FTP.

Do you have a recommendation on a Windows based FTP client that still works with the PLC's.

The reason I bring this up, is that you have used FileZilla as sort of a standard FTP client for use with both the PLC web-server and the PLC's filesystem and FTP fileserver documentation.  And right now I can't get it to work...

Gary D.

32
Gentlemen,

Some of my favorite things that came with the addition of floating point support are the addition of local variables, custom functions that accept arguments and custom functions that return a value.

I think that it is very limiting that the only data type that is supported for the local variables, arguments and return values are floating point.  However, there are lots of cases where a 32-bit integer is much more useful.  

I understand that the the Bits2Float(n) and Float2Bits(n) functions can be used as sort of a "C-like" cast, that can allow a float variable to behave integer, but this mechanism is very awkward.

As an example, I'd like to use the local variable, %[1] as an integer:

%[1] = Bits2Float(3)
%[1] = Bits2Float(Float2Bits(%[1])/2)
[/color][/font]

Now I know that with the #DefineLocal I can make this code a little more readable, but it is still tricky:

#DefineLocal ILocal = Float2Bits(%[1])
#DefineLocal ILocalF = %[1]

ILocalF = Bits2Float(3)
ILocalF = Bits2Float(Ilocal/2)
[/color][/font]

This is what I like you guys to think about on future versions of the Fx firmware and the ITrilogi compiler, some sort of limited type definitions.  Some thing on this order:


' Declare a local variable that is to function as a signed 32-bit integer
'
#DefineLocal ILocal = (INT32)%[1]

ILocal = 3              ' Assignment of an integer variable to a local var
ILocal = Ilocal / 2   ' Integer math and an assignment to a local var
[/color][/font]

The cast "(INT32)" could clue the compiler that the type of the data stored at %[1] is an integer and should be treated as such.

Floats are nice, but there are a lot of cases where Floats can NOT do the job.  Try to represent the integer &h7ffffffffffffff with a float!  

If would be even nicer if there was a way to indicate to the compiler the behavior of a custom function so that arguments could be passed to a custom function as an integer and NOT promoted to a float. Think modern programming languages. Some sort of function declaration:


' The following function returns a 32-bit signed intger
'   and takes 2 arguments, the first one is an integer and the second is a float
'
INT32 FunctionX(INT32 A, FLOAT B)  ' function declaration

for i = 1 to 10
    DM32  = FunctionX(i, 3.14159)             ' using the function
next

[/color][/font]

The same function declartion would be needed to be repeated in actual custom function, "FunctionX".

I realize that this is probably  too big a change to a language like TBASIC to support, but I can always ask.

Gary D.



33
Technical support / Sorry, broke the simulator with PIDCompute
« on: May 08, 2015, 07:52:33 PM »
Sorry, but I broke the simulator in i_TRILOGI 7.03 Build 08.

I was working with the PidCompute function and got real different results between hardware and simulation.

This is the entire program:


PIDDef 1, 1.0, 0.333, 0.0, 0.0      ' chn, limit, P, I, D ...

A# = PIDCompute(1, 1.0)         ' A# will be 0.333 with simulator. 0.0 with hardware
[/font][/color]

Target hardware Fx-CPU F90.7

I think that the problem is with the PLC firmware and not the simulator. The issue may be setting the limits argument to PIDDef to a value of 1.  I was expecting the values returned from PIDCompute in the range of -1.000 to +1.000 but only got values of 0.0!

If I program everything using scaled arguments limit = 1000, P = 333.0 the the output from PID compute is 333. I suspect that something in the "new" PIDCompute function was not completely recoded for floating point calculations.

Is there a never version of firmware for the Fx processors?


Gary D.

34
Technical support / PLC Data EEPROM Manager 6.49 build 04
« on: April 20, 2015, 08:57:29 PM »
I am afraid that I've broken the tools, again.

This time it is with the "PLC Data EEPROM Manager" and 32-bit access to EEPROM.

Test hardware FMD1616-10 with FRAM-RTC installed, firmware r82A.

The program does not handle 32-bit integers very well.  There are mistakes in the code that are doing math as if the data is a 16-bit signed value and then sign extends it, incorrectly, to a 32-bit signed.

&H00008000 becomes &HFFFF8000 !

This is the PLC code:

' Quick test of EEP32 behaviors
'
' write a walking 1 pattern in memory
'
C = 1
for i = 1 to 32
   DM32 = C : C = C + C
next

a = 1      ' just a target for a break point

' copy first 32 DM32[] to eep32
for i = 1 to 32
   save_eep32 DM32, i
next

a = 2      ' just a target for a break point

' read eep32 back
'
for i = 1 to 32
   DM32[i+40] = load_eep32(i)
next

a = 3      ' just a target for a break point
[/font][/color]

The test code generates a walking 1 pattern in DM32[] writes this to EEPROM32, then reads it back without problem.

The EEPROM/FRAM manager can't do the same.

Look at location #16 in the jpeg for the problem with &H00008000 the EEPROM manger things that this location is &HFFFF8000!

The ".csv" file that can be produced contains the same error.

If the ".csv" file is edited and corrected then the value &H00008000 is loaded into EEPROM correctly without the 16/32 bit sign extension mistake.

The EEPROM manager has other problems with "reading" 32 bit values.  An example is if the value &H001BF5A (114522 decimal) is stored in EEPROM, the EEPROM manager will display it as &H0000BFA5. The EEPROM manager has lost the most significant 16 bits of the integer.  This is another 16/32 bit boundary issue.

I have a question.  If I have a file in .CSV format, how does the EEPROM/FRAM manager "know" if I want it to load the integer data as 16 vs 32 bit?  There doesn't seem to be anything in the .CSV file that specifies the data size/addressing scheme.

Gary D

35
Technical support / Get_IPAddr breaks Simulator in 7.03 build 6
« on: February 06, 2015, 02:01:06 PM »
I just broke the simulator, again.

This is the code:

print #1 "before offending statement"
Get_IPAddr 1
print #1 "after offending statement"
[/font][/color]

The Get_IPAddr 1 hangs the simulator and the second print #1 statement never executes.  I assume that the implementation of Get_IPAddr crashed Java.

Get_SubNet, Get_Gateway, Get_SMTP and Get_DNS crash the simulator, also.

I didn't try the Set_xxxx statements to see if they crash the simulator.

The work around is to set a RELAY when running in simulation.  In the  custom functions that have these types of statements, test to see if this RELAY is set and then don't attempt to execute the offending statements.


print #1 "before offending statement"
if !TestIO(Simulation)     ' Execute the following ONLY if not running in simulation.
    Get_IPAddr 1
endif
print #1 "after offending statement"
[/font][/color]

I think that a possible workaround for simulation is to use the status(5) function.  On physical hardware, this function returns a non-zero value related to firmware revision.  On the simulator it returns 0.  I can use this fact to conditionally skip code that breaks the simulator.

It would still be nice if the Get_xxxx stuff didn't break the simulator.

Gary D.

36
Technical support / str$ handiling of negative float values
« on: January 14, 2015, 05:36:12 PM »
Hi all,

I was sort of surprised by the behavior of the str$(x#,w) function when x# was a negative value.  -3 can be displayed as -2!

This experiment was only run in the simulator in i-TRiLOGI V 7.03 build 6.  I did not run this code on actual hardware, sorry.

This is my test code:

' Display Float
'
i = -3
while (i < 4)
   i# = i
   print #2 "Value: ";i;         ' print integer value
   print #2 " "; str$(i#);      ' float with default formatting
   print #2 " "; str$(i#,-3);      ' float with 3 decimal points
   print #2 " "; str$(i#,0)      ' float rounded to nearest integer

   i = i + 1

endwhile
[/color]

This is what I saw:

Value: -3 -3.0000000 -2.999 -2
Value: -2 -2.0000000 -1.999 -1
Value: -1 -1.0000000 -0.999 0
Value: 0 +0.0 +0.000 0
Value: 1 +1.0000000 +1.000 1
Value: 2 +2.0000000 +2.000 2
Value: 3 +3.0000000 +3.000 3
[/color]

I checked the bit pattern of the floating point values and saw that they represented exactly -3, -2 and -1, but if I used the str$(x#, w) statement, the strings did not represent whole integer values.

The str$(x#,0) format, which is documented as "Rounded to the nearest integer" thinks that the closest integer to -3 is -2???  I sort of think that the nearest integer to -3 is actually -3.

Am I expecting too much?

Also another fun fact about TBASIC.  The following code will not work as expected:

for i = -3 to 3
   i# = i
   print #2 "Value: ";i         ' print integer value
next
[/color]

Oh, I expected that the code between the for and next keywords would be executed for values of "I" from -3 to 3...

Interestingly, "I" is initialized to &H0000FFFD which is not -3 (for a 32-bit signed integer).  This results in the initial value of "I" being greater than the limit value of 3, so the code between for and next keywords is not evaluated.  If "I" had been a 16-bit signed value then %HFFFD is -3.  I am guessing that for/next can only work with unsigned values between 0 and 32767.  I'm guessing that this is real old code "feature".

Best regards,

Gary D


37
Technical support / HSCDEF fn_num issue with i-TRiLOGI 7.03
« on: January 07, 2015, 04:48:00 PM »
The HSCDEF statement does not tolerate the "name" of the custom function but requires the numeric constant for the 2nd argument.  This seems like an oversight.

The following code snippet will not compile.  "Accumulate" is the name of custom function #4. No error message is generated indicating that this syntax is unacceptable.


HSCDEF 1, Accumulate ,9999
[/color]

This code will compile:


HSCDEF 1, 4 ,9999
[/color]

It would be nice if the compiler could indicate the failure.  

It would be better if the HSCDEF statement could accept the the "name" of the custom function.

Best regards,

Gary D.

38
Technical support / i-TRiLOGI V7.03 User interaface problems.
« on: October 23, 2014, 09:59:51 PM »
I've encountered a bunch of issues with the user interface in V7.03
  • Define Variable Names.  It is nearly impossible to delete a row in the table. Right clicking to get the pop up menu and selecting "Delete Row" does not seem to work.
  • Cut, Delete Ladder logic commands that bring up the dialog that has the "From Circuit #" and "To Circuit #" boxes has problems if you change the "From Circuit #" to anything but the current Circuit number.  Odd things get deleted.  If you have to scroll down the ladder logic to verify a ladder logic line number the cut/delete commands will usually delete some random stuff. This is a very scary behavior.
  • Ladder logic editor problems with the "Select a Sequencer" window.  If you press "enter" to confirm that you want the highlighted Sequencer 1..8 will insert a contact for SeqN:0 without bringing up the "Enter Step #(0-31) dialog.  The only way to get the "Enter Step # (0-31) dialog is to left click on the "select a Sequencer" window.
  • On a ladder rung that ends with {dCustF} it is not possible to bring up the "Edit Label Name" dialog.  To change the name you either have to delete the {dCustF} terminator and enter a new one or you have to add a new one in parallel and delete the original.  The "Edit Label Name" dialog works for most other contacts and terminators.
  • The "Edit" menu hints that Ctrl-X can be used as a short cut for Cut Circuit.  Ctrl-X seems to be ignored by the ladder logic editor.
  • The use of the Delete key in the ladder logic editor (to delete a contact) affects the state of the text editor.  If you use the Delete key, then the text editor changes behavior to overwrite mode.  To fix this you have to press the "Insert" key while in the text editor (custom functions).  This is annoying and messy.
  • If you use "Find & Replace I/O Labels" in the ladder logic, it will take you to the rung that contains the label. If you then attempt to scroll up or down in the ladder logic you are taken back to the first rung in the logic.  To keep this from happening after using the "Find" I click the "Circuit # nn" button and enter the circuit number that the is shown on the screen, now the screen allows me to scroll.

Just add 'em to the list.

Gary D.

39
Technical support / Correct Usage of #defineLocal, i-TRiLOGi V7
« on: October 22, 2014, 10:39:08 AM »
OK, you added a new "keyword", #defineLocal.  How do you use it?
  • The text "#defineLocal" is highlighted by the syntax highlighter.
  • Clicking on #defineLocal" does not bring up any "keyword helps"
  • #defineLocal" is not in the list of "keyword helps"
  • The TL7ReferenceAddendum.pdf mentions the #defineLocal, but gives no hint or example of how to use it.
Ok.  So I'm taking guesses.  I wrote the following custom function (one of a series of tests):


#defineLocal ILocal %[1]%

For ILocal = 1 to 10
   print #1 ILocal
next
[/color]

I wrote ladder logic that could invoke the custom function (I know about the compiler optimization for orphaned functions).

If I run the "Compile Only" option, the code compiles without complaint (no syntax error).

If I comment out the #defineLocal line, the code fails to compile (as it should).  This suggests that my usage of the #defineLocal is pretty close to what the compiler expects.

If I click on the "Run (All I/O Reset) menu, the simulator does not run and no error messages are presented.  The presence of #defineLocal breaks the simulator!

OK.  So how was this #defineLocal supposed to be used?

Gary D.

40
Technical support / Java and i-TRiLOGI
« on: October 03, 2014, 10:02:11 PM »
I know this is an old subject, but it keeps me awake at night.

C:\Program Files\Java\j2re1.4.2_19\bin\java.exe  just is not happy with current windows operating systems.    i-TRiLOGI windows get messed up if you move them, i-TRILOGI messes up Outlook and other programs when run this ancient unsupported versions of Java.

If I force i-TRILOGI to run with current Java, I have none of these problems.

I've attached a sample of what happens with j2re1.4.2_19.  If I run the i-TRiLOGI stuff with the current java, I don't have all of these problems.

In the old days I could edit the "TL6.BAT" file and newer versions of Java to run.  This file is still present in the install directory but is no longer used.

Is there anyway with your new TL6/TL7 launcher to select what version of Java is to be used?

I'd love to use a version of Java that works with Win7 64 bit for the development tools.  I'm OK with the old Java for TLServer (it doesn't really have a user interface).

Sorry to bring up this old festering issue,

Gary D

41
Technical support / RESTART Statement and New IP address
« on: September 28, 2014, 02:39:28 PM »
I'm struggling with the RESTART statement. I'm attempting to have the PLC set/change it's own IP address.  The documentation states:

"To perform a cold reboot of the PLC from within a CusFn. The effect is identical to a power-on-reset except that you execute this command without turning OFF power to the PLC.
RESTART may be necessary for some changes to take effect, such as for the PLC to assume new IP address after executing the SET_IP command."


My observations are that The RESTART statement does not do the job.  I find that I still must power off the PLC to get the IP to change.

I am using 2 custom functions for my debug code, "Init" once at 1st.Scan and displays the current IP address using the new Get_IPAddr.  The second custom function is "ToggleIP" it runs only in response to an INPUT and attempts to change the IP address back and forth between "192.168.1.16:9080" and "192.168.1.17:9080".

Init looks like this:

' Init
'
Get_IPAddr 1         ' Get PLC IP addres in DM[1..5]
A$ = str$(DM[1])+"."+str$(DM[2])+"."+str$(DM[3])+"."+str$(DM[4])+":"+str$(DM[5])

SetLCD 0,1,"\01"      ' Clear LCD display
SetLCD 0,1,Chr$(12)   ' No cursor
SetLCD 1,1, "PLC IP Address:"
SetLCD 2,1, A$
[/color]
ToggleIP looks like this:

' ToggleIP
'
Get_IPAddr 1         ' Get PLC IP addres in DM[1..5]
A$ = str$(DM[1])+"."+str$(DM[2])+"."+str$(DM[3])+"."+str$(DM[4])+":"+str$(DM[5])

SetLCD 0,1,"\01"      ' Clear LCD display
SetLCD 0,1,Chr$(12)   ' No cursor
SetLCD 1,1, "Current IP"
SetLCD 2,1, A$

Delay 4000      ' kill some time so the LCD can be read


' Toggle  IP address between 192.168.1.16:9080 and 192.168.1.17:9080
'
if DM[4] = 16
   DM[4] = 17
else
   DM[4] = 16
endif
A$ = str$(DM[1])+"."+str$(DM[2])+"."+str$(DM[3])+"."+str$(DM[4])+":"+str$(DM[5])

SetLCD 3,1, "Next IP"
SetLCD 4,1, A$
Delay 4000      ' kill some time so the LCD can be read

Set_IPAddr 1   ' Set new IP address

RESET         ' Update flash memory that holds the IP variables

RESTART         ' Force a cold reboot to restart the PLC and actually configure the
            '  PLC to the changed IP address.

[/color]

If I toggle the INPUT, I can see on the LCD, that the ToggleIP custom function runs.  I am convinced that the RESTART statement does restart the ladder logic scanning mechanism. However, the IP address shown on the LCD after the RESTAT, is not the actual IP address of the PLC.  The actual IP address is unchanged!

If I power down the PLC, then the PLC's IP does change to match the value on the LCD.

This is my evidence that RESTART is not the same the ultimate reset caused by killing power to the PLC.

Hardware info:  FMD1616 r82A

What am I missing?

Gary D

42
Technical support / Controlling PLC via Web Browser, LCD Display
« on: September 03, 2014, 01:56:13 PM »
I've been working with the "Controlling PLC via Web Browser" scripts that is described in the "Frequently Ask Questions" portion of forum.

I've noticed that the LCD portion of the web page uses a variable pitch font and left justifies the LCD strings. This makes the Web version of the 4x20 display not look very much like the LCD.

I found that I could fix the font issue by adding the line to this section of the "0-C001-01.html" file:

.LCDline {
   background-color: #FFFFCC;
   border: solid 1px #FFFFCC;
   color: #000000;
   font-family: Courier;
   position: absolute;
   width:400px;
   height:20px;
}


So now my question, "Is there a way to specify that the LCDline text is not to be stripped of white space and left-justified?"

The attached jpeg shows the web page and what the LCD should look like.

Gary D

43
Technical support / Is there a <FTPAPPEND> command?
« on: August 22, 2014, 09:43:49 PM »
I've been using the <FTPUPLD xxxx> network command to upload data files from the PLC to my client's FTP file server.  My client would like the PLC to be able to append data to an existing file via FTP.

I've explained that I do not believe that there is an "undocumented" FTPAPPEND network command.  

So the question is, "have I been telling my the truth?"

Best regards,

Gary d

44
Technical support / Type checking problem in i=TRiLOGI V6.48
« on: August 08, 2014, 05:19:30 PM »
I'm getting syntax errors while I compile the following:


for i = 1 to 8
   print #1 Load_EEP$(i)
next
[/font][/color]

but this works:

for i = 1 to 8
   A$ = Load_EEP$(i)
   print #1 A$
next
[/font][/color]

I think that your syntax checker for the Print #n statement has some type checking issues.

I've attached a screen shot showing the error messages

Best regards,

Gary D.

45
Technical support / NS TCPCONNECT Behaviors
« on: July 28, 2014, 03:55:24 PM »
I have been testing the behavior of the TCPCONNECT tag to access network timeservers.  The test is being done on an FMD1616 PLC with firmware r82A.

This post is more to provide information on how things work then to ask a question.  

My observations on the behavior of this command are as follows:
  • The TCPCONNECT tag is non-blocking. The execution time of the statement,  print #4 "<TCPCONNECT 64.250.229.100:13>" is about 450 us.  I have not observed it to exceed 500 us.
  • Polling for command completion using INPUT$(4) can fail.  It is possible to poll forever and not receive either a response from the remote device that you are attempting to connect to nor an error message from the PLC TCP/IP firmware.
  • If the PLC TCP/IP firmware does return an error message, this message is received iin 2 seconds or less. This seems to suggest the the TCP/IP firmware does have a 2 second timeout mechanism.
  • The results with polling using INPUT$(4) can be different if on-line monitoring is being used vs. the PLC being physically disconnected from the Ethernet bus.
  • Status(3) behavior. Immediately after issuing the TCPCONNECT tag, Status(3) returns a value of 0 indicating that the command is being processed.  Status(3) will return a value of 1 when a TCP/IP connection has been established. The actual response message from the server is not available for 40ms after Status(3) indicates a TCP/IP connection.
  • In the event that the timeserver drops the connection, Status(3) will go back to a value of 0, but there is no response message from the server and the PLC TCP/IP firmware does not post an error message.  

This is the PLC test code that I was using to make these evaluations and measurements

' Demo of NIST command behavior
'
' the integer variables a,b,c,d and e are used to calculate elapsed time
'
d = 0
e = 0
A$ = "<TCPCONNECT 64.250.229.100:13>"   'Connect to time server

print #1 ">>> "+A$
a = status(21)               ' timestamp: Start
PRINT #4 A$                   ' Send TCP command
b = status(21)               ' timestamp: Command overhead
Print #1 "         Status(3): "; status(3)

' poll for message
'
i = 3000                  ' max poll time in ms
A$ = INPUT$(4)
while i and (len(A$) = 0)
   delay 1

   ' this code is looking for status(3) to go from 0..1
   '  indicating that the there was a connection to the
   '  time server was established
   '
   if (d = 0)            
      if (status(3))
         d = status(21)
      endif
   endif

   ' this code is looking for status(3) to go from 1..0
   '  indicating that the connection to the time server
   '  was dropped
   '
   if (d and (e = 0))            
      if (status(3) = 0)
         e = status(21)
      endif
   endif

   A$ = INPUT$(4)
   i = i -1
endwhile
c = status(21)               ' timestamp: Command complete


print #1 "     Print #4 time: " + str$(b-a)
if (d)
   print #1 "      Connect time: " + str$(d-b)
else
   print #1 "Failed to Connect"
endif
if (e)
   print #1 "Connection dropped: " + str$(e-b)
endif

print #1 "    INPUT$(4) time: " + str$(c-b)
print #1 "      Cmd Response: " + A$
A$ = INPUT$(4)
print #1 "      Cmd Response: " + A$
Print #1 "         Status(3): "; status(3)

Print #4 "</>"               ' close connection
[/font][/color]

The print #1 statements send messages over a serial port that was used to monitor the behaviors.

The following are the descriptions of the test cases, the captured results and my annotations:

/*
   This is what I observed for a successful connection:

>>> <TCPCONNECT 64.250.229.100:13>
         Status(3): 0
     Print #4 time: 4344         <-- non-blocking TCP command
      Connect time: 434091         <-- TCP connected in 43.4ms
    INPUT$(4) time: 856717         <-- response avialabe in 85.7ms
      Cmd Response:
      Cmd Response: 56866 14-07-28 19:31:53 50 0 0 906.4 UTC(NIST) *
         Status(3): 1            <-- TCP still connected?

   Forced connection failure.  Ethernet cable disconnected. Online monitoring
   not used.

>>> <TCPCONNECT 64.250.229.100:13>
         Status(3): 0
     Print #4 time: 4394         <-- non-blocking TCP command         
Failed to Connect               <-- TCP did not connect
    INPUT$(4) time: 19739621      <-- 2 second timout
      Cmd Response: ERR:01-Connect Fail   <-- useful error message
      Cmd Response:
         Status(3): 0            <-- TCP not connected

   Forced connection failure.  Online monitoring established and then the
   Ethernet cable was disconnected.

>>> <TCPCONNECT 64.250.229.100:13>
         Status(3): 0
     Print #4 time: 4323         <- non-blocking TCP command
Failed to Connect               <-- TCP did not connect
    INPUT$(4) time: 30026965      <-- This is test firmware timout
      Cmd Response:               <-- No error message from TCP/IP stack
      Cmd Response:
         Status(3): 0


   This is what I see if we use a valid URL with wrong port number:

>>> <TCPCONNECT 64.250.229.100>
         Status(3): 0
     Print #4 time: 2487         <-- non-blocking TCP command
Failed to Connect               <-- TCP did not connect
    INPUT$(4) time: 4064         <-- very little delay to error msg
      Cmd Response: ERR:03-Invalid URL   <-- useful error message
      Cmd Response:
         Status(3): 0

   This is what I see if the server initially connects then drops the connection
   without sending the time response:

>>> <TCPCONNECT 64.250.229.100:13>
         Status(3): 0            
     Print #4 time: 4476         <-- non-blocking TCP command
      Connect time: 440977         <-- 44ms to TCP connection indication
Connection dropped: 1262044         <-- 126ms to TCP connection loss
    INPUT$(4) time: 30023768      <-- timeout in test code
      Cmd Response:               <-- No error message
      Cmd Response:
         Status(3): 0
 */
[/font][/color]

Gary D

Pages: 1 2 [3] 4 5