Internet PLC Forum

Your approach is pretty well though out.

I took a look at one of my nano-10 boards and traced the output circuit.  They appear to use a desecrate power MOSFET with a 5.6K pull up with a red LED.  The interesting observation is that the pull up is not tied directly to the 24V input, but to a diode connected to the 24V input.

The single diode will prevent current from the 48V supply from flowing through your load to the 24V supply.  The motor won't turn and the output LEDs won't pop because of the reverse bias.

But, there is only one diode in the nano output circuit and it is shared by all 4 outputs.  If you have a load connected to 48V and the output is
 off, the other outputs will be pulled up to your 48V supply through your load.  This may cause some issuses (output LEDs may melt and/or the 5.6K resistors may momentarily emit light/smoke when the other outputs go active.  The current that flows thru the other 3 output's LEDs will be sourced through your motor load.

You still may want to consider an external solution.  If you are already using a SSR to handle the motor direction issue, you might want to use another SSR for the pwd issue.  You may want to look at something called an "h-bridge driver".


Gary d

You're size requirements will be difficult to meet.  

Do a google search for a Mean Well DR-UPS40.  This unit provides the charge controller functionallity.  You have to supply the back up batteries and and a 24VDC supply.  The DC supply must be sized to be able to run your system + another 2A to be used for battery charging.

The DR-UPS40 runs off the 24VDC supply, so it doesn't care if your local power is 230VAC.

It's a good starting point and at about $60 you can't go wrong.  You won't get too much custom built at this price.

Gary d

I assume that if you are using a quadrature encoder (A and B phase outputs) that you are building some nature of servo positioning system.

Using a simple circuit such as what can be done with a CD4013 or CD4040 to divide the incoming frequency of both phases by 4 will not preserve the phase relationship of the original A and B signals. This will confuse the crap out of the quadrature decode mechanism in the PLC.  

If you are using a quadrature encoder and "looking" at only a single phase, then I assume that you are only interested in counting shaft revolutions.  If this is the case then, I'd ask, "why are you using an expensive encoder when a cheaper one would be fine?".

If you are only interested in counting shaft revolutions, and cannot use a more appropriate encoder, then a simple divide by 4 circuit might be a reasonable method to better match your system to the PLCs capabilities.

Gary d

Look at the TBASIC function, CRC16.  This will probably do the trick.

Gary d

The CHR$(n) function is incorrectly documented:

"To convert a number n into its corresponding ASCII character. n must be a numeric constant (0 to 255)"

The range of n is limited to 1..255.  This limitation is consistent with most variants of BASIC. The value of &H00 is used to mark the end of a string in many versions of BASIC.  Your documentation for ASC(x$,n) hints that this is the case for TBASIC.

If n is set to a value of 0, it will break the simulator in TRiLOGI V 6.40 build 02.

The following code will compiles w/o error but fails during simulation.  No error message is issued by the simulator, but the 2nd line of code is not executed (A is not set to 255).


A$ = chr$(0)      ' illegal value for chr$()
A = 255           ' this line of code does not execute


Just add it to your list of small things.

Gary D.

I don't actually think that I can really help all that much.

Your description that strings change value with time is nonsensical. If a string variable changes, it is because your programming changed the string.

Sorry,

Gary d

In regards to your error in compilation

PRINT #1 "50003402000E000DFF" + STR$(C$) +"50"

This line should NOT compile.  The problem is with str$(c$).  Str$() expects an integer as an argument.  C$ is a string!

Sorry for not catching this, earlier.

Gary d

Can't help with your PRINT statement.  The isolated statement complies for me.  I'm guessing that your have messed up the "(" or some other syntax junk in a previous line.

In regards to calculating a Checksum (sumcheck) it is pretty simple.

If you concatenate the strings that need the the sumcheck in  A$, then call a custom function that appends the appropriate sumcheck value onto A$, then you can send A$ on it's way.  Something like this is a good starting point:


' SumCheck
'
' On entry A$ holds ASCII string
'
' On exit A$ holds ASCII string with checksum appended
'   Integer variable used: I,S,N
'
'
S = 0               'Starting point for SumCheck
N = LEN(A$)   

FOR I = 1 TO N         ' For each ASCII char in string
   S = S + ASC(A$,I)
NEXT

S = S & &HFF         ' Toss out everything but 8 bits
A$ = A$ + HEX$(S,2)   ' Tack on sucmcheck



Since there are no absolute rules on how checksums are calculated, you may need to adjust the algorithm to fit the rules for your communication protocol.

Gary d.