suggestions for enhancements to webcontrol (not 32)

[CAI_Support]

Hi Todster,
 
We are trying to digest what you and Ross suggested.  Ross suggested instead of VARx, an IOID by the name VAR with parameter  being used. When the parameter changes, the VAR will reference to the value of that VARx.  From my understanding, you suggestion is to have the reference value change the ratio of the VARx being applied.  Are the ratio is based on second, minute, or other time base? What is the start point, I assume the older value? Assume AIP1 and AIP2 are changing over the time.
 
We will look into the possibility of each suggestion. Currently we can not commit if we can implement or not. We want to understand clearly exactly each instruction will have what behavior. 
 
Thanks for the suggestions.

 

[todster]

No, no, no, no.  I'm suggesting the same as Ross.  I'm horrible at explaining. The (xxxx) could be used anywhere to refer to the contents of whatever (xxx) contains. Ross is a lot better at explaining this than I am. I'm more of a rocket scientist and Ross is the one that actually knows what the parts are called.
In that example I was thinking to far ahead. Var doesn't have the ability to be incremented by a user specified amount, (yet).  I was trying to show that the value of the analog input (AI1) could also be used by referring to the I/O identifier instead of a fixed number.
Rather than providing a static value for the operand, we want to make it dynamic by saying that the I/O identifier in parenthesis contains the value of the operand.
Lets say I want to do a rotate right based on the value of var1. Var1 is dynamically changed because it is based on the current   value of ALLIN. In this example inputs 2 and 3 are on. The rest are off. The I/O identifier contains 00000110 or the number 6.
 
ANDB ALLIN 15 VAR1     VAR1 now contains binary 0110 or the number 6
ROTR VAR2 (VAR1) VAR2   is now the same as     Rotate VAR2 6 VAR2
Now the inputs change and only input 1 is on. The content of VAR1 is now the number 1 or binary 1.
ROTR VAR2 (VAR1) VAR2   is now the same as     Rotate VAR2 1 VAR2
 
 
 

 

[rossw]

I'll attempt to explain in simplified terms what I think would be useful, and would have saved me countless lines of (almost) replicated code.
Using one register as a "run-time-evaluated" number. So during execution (rather than during compilation), the value of something - identifier yet to be specified, but lets just make it something clear and different from anything else, I'll use parenthesis {}
 
Any expression that would normally be a number, could be replaced by    {ram1}   or  {var6}  etc, and they would be evaluated at the time of execution first.
 
So
    set   ram1=1
    add var{ram1} 10 var{ram1}    is equivalent to      add var1 10 var1
 
The difference is, the former can be included in a subroutine, or a loop, and be used for WHATEVER register/var is relevant.
So timers and counters etc can be just "pointed to" and a subroutine called - without having to write almost identical duplicates for each.
 
 
Another thing I asked for while we're on the list of "things to consider" was UNIONS.
 
Add some additional keywords. I tried to explain this before but I don't think anyone "got" it.
We have RAM1 which is a 32-bit word.
Why not have a union, lets have 4 bytes:
RAMBYTE1, RAMBYTE2, RAMBYTE3 and RAMBYTE4.
RAMBYTE1 would be just bits 0-7 of RAM1.
RAMBYTE2 would be just bits 8-15 of RAM1.
RAMBYTE2 would be just bits 8-15 of RAM1.
RAMBYTE3 would be just bits 16-23 of RAM1.
RAMBYTE4 would be just bits 24-31 of RAM1.
 
This isn't a good example of how it could be done, but it's AN example: http://elecurls.tripod.com/pmr.htm
 
Could do the same thing with bits. That'd be really cool

 

[CAI_Support]

Thanks for the suggestions. I think to have RAMBYTE access is possible, that can be added without using additional RAM.  That means to add 64 additional IO identifiers.
 
To have indirect reference, that may need to rework the PLC engine, since current structure only allow up to four elements to be passed in, also current PLC engine compiled delay as numerical number, not variable name.  Your example will require five or potentially six parameters: set var{ram1} var{ram2} var{ram3}. We may need to redesign portion of our logic to be able to make it work.
 
Thanks for all the suggestions, we will consider all the suggestions, even not all of them can be done immediately.

 

[CAI_Support]

This RAMBYTE can be work out by using ROTR and ANDB, for example,  RAM1 has four bytes you want to get each byte, you can do
 
ANDB RAM1 255 RAM2
RAM2 at this point contains the byte from bit 0 to 7.
 
ROTR RAM1 8 RAM1
ANDB RAM1 255 RAM2
now, RAM2 contains the original byte 2 of RAM1,
 
Not the simplest way to just use RAMBYTE1, etc, but it can work for now.

 

[rossw]

This RAMBYTE can be work out by using ROTR and ANDB, for example,  RAM1 has four bytes you want to get each byte, you can do
 
ANDB RAM1 255 RAM2
RAM2 at this point contains the byte from bit 0 to 7.
 
ROTR RAM1 8 RAM1
ANDB RAM1 255 RAM2
now, RAM2 contains the original byte 2 of RAM1,
 
Not the simplest way to just use RAMBYTE1, etc, but it can work for now.

 
Yes, there are ways to achieve a similar result, but a union is a FAR superior way. It requires no additional processor instructions, doesn't destroy the original register, doesn't require the use of any other registers, is obvious  in use and function, etc.

 

[CAI_Support]

Should we consider implement RAM1BYTE1, RAM1BYTE2, RAM1BYTE3 RAM1BYTE4, RAM2BYTE1, RAM2BYTE2,... VAR1BYTE1, VAR1BYTE2, ...etc total 64 additional IO identifiers? 
To implement them, we will do calculation internally, since internal data structure for VARs is not directly accessed, rather through another structure with its properties.

 

[todster]

How will it affect scan time?

 

[CAI_Support]

PLC executed line by line, the additional IO identifiers will not change the executing speed. When these new identifier being called, we will in firmware calculate the value.  It just looks messy with a lot of additional identifiers, But if that helps making PLC logic simpler, it would worth it.

 

[rossw]

TTL Input 1 can currently be used as
 (1) TTL input
 (2) Frequency measurement
 (3) Externally clocked counter
 
Is it possible or practical to use it to measure period?
Specifically, to measure the time an input spends low after a high-to-low transition (or high, after a low-to-high transition)?
The polarity isn't super critical. If it wasn't set as a parameter, it could be always measure the high time, perhaps using the input invert logic to operate it the other way?
 
A time resolution of say, 10uS would be useful, but anything better than that would be great.
 
Apart from any number of other things this would be useful for, would be with the recent discussion of water depth measuring.
If we could measure the replies from the $1 ultrasonic distance kits for arduino, they have a typical measurement range of in excess of 10 feet with a resolution of as little as 1/8" which would be fantastic for measuring tank levels, watching for water rising in a sump etc. (I currently use a honeywell system to monitor my tanks, but they're far too expensive for what I need - and a webcontrol + cheap ultrasonic head would be far far more useful, turning on and off pumps, sending alarms etc)

 

[CAI_Support]

Hi Ross,
 
Thanks for your suggestion. It is possible to do that with a spare pin on the 8 pin header.  However, to do that, we must remove some functions, since there is really no RAM to be used.  Since MAXIM is discontinue its DS2450 chip, we could consider remove the upper 4 analog input through that DS2450 on 1-wire bus.  Do not know if anyone object to that.
 
Once again, that is just a possibility. When we start coding it, it might not fit into the code space of the chip.  We got confirmation from Microchip engineers that the datasheet for the CPU used to have wrong configuration information. Now, they have corrected that datasheet after our board already made, so that doing what we described above is possible now through the spare pin header.  It will require addition hardware module involved doing accurate time measurement.  We will check with Microchip engineers to see if we could configure the chip to use that hardware resources.
 
If this is doable, then TTL 1 will not be able to do frequency measurement or counter, because that timer resources will be used for this purpose. But TTL1 input can work as input at the same time.

 

[rossw]

Another thought....
 
With the mentioned possible (probable?) removal of DS2425 4-channel A-D support, how about this?
Not everyone wants or needs Humidity input. Certainly, in the majority of cases I need more A/D channels, I don't need it.
You already have an input configuration screen where you can determine what TTL input 1 does - and since the humidity A/D input is just a 0-5V input with special linearizing code (presume a LUT) in firmware - let us select the humidity input as either humidity (with conversion to 0-100% as appropriate), OR 0-5V analog input.
 
This would give us 4, full, 10-bit ADC inputs where we need them.
I'm considering making a specialised version of my webamp board that would take 8 inputs (not 4), use one output from the PLC to select which bank is required and multiplex 8 inputs to 4 ADC channels. (This works far better than trying to mux 6 inputs to 3 channels).
 
It should be achievable with no hardware changes to the existing WebControl board either, and as it's a configuration change, shouldn't need any additional RAM.

 

[CAI_Support]

Hi Ross,
 
Thanks for your suggestion. Humidity sensor does have a different resistor divider than normal analog input, due to Honeywell humidity sensor has a range that is a sub range of regular analog input. That input has no over voltage protection, and full scale (1024) input is about 6.6V. If the firmware is 3.02.16 and later, you could access AIP4 in the PLC with above mentioned range.

 

[rossw]

Hi Ross,
 
Thanks for your suggestion. Humidity sensor does have a different resistor divider than normal analog input, due to Honeywell humidity sensor has a range that is a sub range of regular analog input. That input has no over voltage protection, and full scale (1024) input is about 6.6V. If the firmware is 3.02.16 and later, you could access AIP4 in the PLC with above mentioned range.

 
Ahh, I hadn't caught up with being able to use AIP4, or the voltage range. That's really good to know!
 
It would be entirely possible for me to use a standard 6V2 zener clamp on the output of an opamp - not ideal, but probably close enough!
Can you tell me what the input arrangement is, exactly? Is it just a resistive divider? If so, what values? How much over-voltage would be "safe" without damaging the chip? (Eg, if the input resistance is enough to limit input current to say 1-2mA, will the devices input protection diodes handle that?) Perhaps even a 6V8 zener would be ok - allow minimum top-end crushing while affording adequate overvoltage protection??

 

[CAI_Support]

Hi Ross,
 
R12 and R13 both 100K divide the analog input for humidity sensor. If you like to change that by replace R12 to 200K or change R13 to 50K, then they will be 10V full scale.  Please note once change made to those resistors, humidity sensor will no longer provide meaningful result.
 
You will need to add protection for analog input, since microprocessor's analog input does not take much current.