1
Technical support / Re:FRAM-RTC memory addressing
« on: February 26, 2011, 08:46:52 AM »
Reseating in socket solved the problem. Thank you.
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.
Pages: [1] 2
2
Technical support / FRAM-RTC memory addressing
« on: February 25, 2011, 01:03:31 PM »
I am using a Nano-10 in a data logging application
with FRAM-RTC installed
Memory addresses above 1024 do not seem to work.
SAVE_EEP and LOAD_EEP return 0 rather than attempted stored value.
Also EEP utility in latest TRIlogy version limits access above 1024
Is 11K words FRAM contiguous? Start address? End Address?
Please advise.
with FRAM-RTC installed
Memory addresses above 1024 do not seem to work.
SAVE_EEP and LOAD_EEP return 0 rather than attempted stored value.
Also EEP utility in latest TRIlogy version limits access above 1024
Is 11K words FRAM contiguous? Start address? End Address?
Please advise.
3
Technical support / Nano10 Network Services via COM1
« on: January 26, 2011, 12:49:49 PM »
I have a Nano10 working nicely logging events and storing files
using the Ethernet connection.
In some locations where this application would fit the nearest
jack is too far away and the wiring cost makes the project too expensive to justify.
I have found a reasonable wireless link solution: RS485 to a wireless adapter to a wireless adapter to USB to a PC where TLServer could run. This is amounts to a serial link from the Nano10 to TLServer.
Will this work? I need to store files, sync time, and possibly send e-mail
using the Ethernet connection.
In some locations where this application would fit the nearest
jack is too far away and the wiring cost makes the project too expensive to justify.
I have found a reasonable wireless link solution: RS485 to a wireless adapter to a wireless adapter to USB to a PC where TLServer could run. This is amounts to a serial link from the Nano10 to TLServer.
Will this work? I need to store files, sync time, and possibly send e-mail
4
Technical support / Re:Nano10 Remote File Services
« on: October 28, 2010, 05:40:21 AM »
You may find the following reference useful:
http://msdn.microsoft.com/en-us/library/aa505957.aspx
Apparently, two segments are better than one.
http://msdn.microsoft.com/en-us/library/aa505957.aspx
Apparently, two segments are better than one.
5
Technical support / Re:Nano10 Remote File Services
« on: October 28, 2010, 04:14:58 AM »
The Windows registry modification is certainly possible, but each version of Windows may have different modifications required and this approach is not really a universal solution.
I understand the reluctance to make a firmware modification on a stable product, but when performance is impacted so dramatically as to open up a whole new class of applications,
(those that need or would benefit from high bandwidth), I think the business decision becomes much clearer.
Please consider this: if every packet sent from the PLC was immediately followed by a "dummy packet" whose entire purpose was to trigger an immediate ACK from the Windows TCP stack, would this not eliminate the dreaded 200msec delay?
I am going to be making a business presentation very soon which will include a demonstration of a Nano10 doing a simple control function and some really compelling event logging and email alerts.
I want to keep the discussion focused on the dramatic technical advancements in the cost and ease of implementation of this new generation of networked controllers and especially the compelling business benefits of monitoring and controlling
large numbers of assets spread over a wide geography.
The business people in my audience will be quite accustomed to transferring multi-megabyte files from around the world in a few seconds.
My demonstration would be far more effective if all communications appear to be instantaneous.
I am quite sure this scenario will be repeated thousands of times over the life of this product.
Thank you for listening to your customers and your consistently excellent technical support. These are the things which distinguish you from your competition (along with innovative, cost effective products)
I understand the reluctance to make a firmware modification on a stable product, but when performance is impacted so dramatically as to open up a whole new class of applications,
(those that need or would benefit from high bandwidth), I think the business decision becomes much clearer.
Please consider this: if every packet sent from the PLC was immediately followed by a "dummy packet" whose entire purpose was to trigger an immediate ACK from the Windows TCP stack, would this not eliminate the dreaded 200msec delay?
I am going to be making a business presentation very soon which will include a demonstration of a Nano10 doing a simple control function and some really compelling event logging and email alerts.
I want to keep the discussion focused on the dramatic technical advancements in the cost and ease of implementation of this new generation of networked controllers and especially the compelling business benefits of monitoring and controlling
large numbers of assets spread over a wide geography.
The business people in my audience will be quite accustomed to transferring multi-megabyte files from around the world in a few seconds.
My demonstration would be far more effective if all communications appear to be instantaneous.
I am quite sure this scenario will be repeated thousands of times over the life of this product.
Thank you for listening to your customers and your consistently excellent technical support. These are the things which distinguish you from your competition (along with innovative, cost effective products)
6
Technical support / Re:Nano10 Remote File Services
« on: October 27, 2010, 05:16:43 AM »
Thank you for your prompt and lucid explanation of my comm issues.
The REFRESH instruction in the timer interrupt service routine completely solves my "missed input changes during data transfer" issues.
The 200 msec delayed ACK also completely explains the data transfer speeds I am observing.
My application now works fine, even with the inefficient use of the PRINT #4 in a program loop.
However, I would like to use F series products in future applications which require much higher PLC-to-TLServer ethernet throughput.
It is my understanding that a simple double buffering technique can almost completely eliminate this 200msec delay and dramatically increase TCP throughput. Is this possible in present or near future F series products?
Even with a full 128 byte buffer at (1/200msec) 5 packets per second, 640 bytes per second is quite slow.
The REFRESH instruction in the timer interrupt service routine completely solves my "missed input changes during data transfer" issues.
The 200 msec delayed ACK also completely explains the data transfer speeds I am observing.
My application now works fine, even with the inefficient use of the PRINT #4 in a program loop.
However, I would like to use F series products in future applications which require much higher PLC-to-TLServer ethernet throughput.
It is my understanding that a simple double buffering technique can almost completely eliminate this 200msec delay and dramatically increase TCP throughput. Is this possible in present or near future F series products?
Even with a full 128 byte buffer at (1/200msec) 5 packets per second, 640 bytes per second is quite slow.
7
Technical support / Nano10 Remote File Services
« on: October 24, 2010, 10:25:05 PM »
When using the Remote File Services from a Nano10 to TLServer running on a PC on a LAN, it is taking over ten seconds to append a modest amount of data to a file (25 events: "door open, door closed, etc". plus hour and minute time stamps.
During this time, no scanning of inputs can take place, since the data transfer happens within a loop in a special function similar to your examples in TestEthernet.PC6.
The Timer Interrupt would appear to be a solution but it doesn't seem to work during these data transfers.
Am I missing something?
Are interrupts disabled during this time?
Is there some block transfer capability which would reduce overhead and speed up data transfer?
During this time, no scanning of inputs can take place, since the data transfer happens within a loop in a special function similar to your examples in TestEthernet.PC6.
The Timer Interrupt would appear to be a solution but it doesn't seem to work during these data transfers.
Am I missing something?
Are interrupts disabled during this time?
Is there some block transfer capability which would reduce overhead and speed up data transfer?
8
Technical support / API comm Library
« on: October 05, 2010, 10:08:28 AM »
I would like to develop my own GUI, starting with the well documented sample applet which you have provided.
Where can I download a copy of PLCmon.jar?
Where can I download a copy of PLCmon.jar?
9
Technical support / Cursor commands on Nano10 Virtual LCD
« on: September 24, 2010, 08:07:08 PM »
The "Virtual LCD" on the web page in the Nano10 is a great feature. I'm using it to allow modification of operating parameters remotely. Effectively, it is a zero cost HMI.
It seems to work just like the real LCD, but the cursor commands are not working for me. Is this a supported feature?
It seems to work just like the real LCD, but the cursor commands are not working for me. Is this a supported feature?
10
Technical support / Re:Nano10 SMTP issues
« on: September 24, 2010, 06:25:15 AM »
I tried enclosing the email request within the <RemoteFS> tags (as the Nano10 Users Manual clearly describes) and it works!
Thank you for your excellent support.
Thank you for your excellent support.
11
Technical support / Re:Nano10 SMTP issues
« on: September 24, 2010, 03:31:21 AM »
Thank you for the prompt response.
I am in Ohio and my local ISP is Time Warner.
I will contact them today.
I am already using <REMOTEFS> for data logging.It works nicely, but is rather slow the way I have it implemented. I transfer one sample at a time with a PRINT#4 in a program loop. I do it this way because it sets up the csv file for easy Excel import and manipulation. Since the project ultimately will have (hopefully)many geographically dispersed Nano10's reporting to a single TLServer, I will need a faster, more efficient method...perhaps some form of block transfer.
Any suggestions?
Also, is there a program example of the <REMOTEFS> email
capability?
I am in Ohio and my local ISP is Time Warner.
I will contact them today.
I am already using <REMOTEFS> for data logging.It works nicely, but is rather slow the way I have it implemented. I transfer one sample at a time with a PRINT#4 in a program loop. I do it this way because it sets up the csv file for easy Excel import and manipulation. Since the project ultimately will have (hopefully)many geographically dispersed Nano10's reporting to a single TLServer, I will need a faster, more efficient method...perhaps some form of block transfer.
Any suggestions?
Also, is there a program example of the <REMOTEFS> email
capability?
12
Technical support / Nano10 SMTP issues
« on: September 23, 2010, 06:56:34 PM »
I have a Nano10 doing most everything it was promised:
file services, Internet Time Server polling, even emails.
My problem is the lack of authentification when using the embedded FServer.
I have tried a number of SMTP servers, including Yahoo as in your example, with no success.
When I go through TLServer with the proper authentication
either with the older polling method or the new "tags" approach
(much more useful in my opinion) on Port#1 everything works fine (but not with on line monitoring).
A stand alone PLC without the need for an (always on) PC is an easier sell in an energy conscious "green" environment.
I'm not sure unauthenticated email is such a good thing anyway.
Are there any plans to add this feature?
Can you point me to an SMPT server which does not require authentification?
Please Note: I'm doing development and testing in a typical Linksys WRT100 environment, not using Outlook or Thunderbird
clients.
file services, Internet Time Server polling, even emails.
My problem is the lack of authentification when using the embedded FServer.
I have tried a number of SMTP servers, including Yahoo as in your example, with no success.
When I go through TLServer with the proper authentication
either with the older polling method or the new "tags" approach
(much more useful in my opinion) on Port#1 everything works fine (but not with on line monitoring).
A stand alone PLC without the need for an (always on) PC is an easier sell in an energy conscious "green" environment.
I'm not sure unauthenticated email is such a good thing anyway.
Are there any plans to add this feature?
Can you point me to an SMPT server which does not require authentification?
Please Note: I'm doing development and testing in a typical Linksys WRT100 environment, not using Outlook or Thunderbird
clients.
13
Technical support / Re:XServer comm problems
« on: March 19, 2009, 11:28:49 AM »
I found a few LOAD_EEP and SAVE_EEP statements in my program. Once they were all eliminated, on-line monitoring through XServer started working perfectly.
I never would have suspected this without your suggestion.
Perhaps a warning in the Programmer's Reference Manual is warranted.
Thanks again for your help.
I never would have suspected this without your suggestion.
Perhaps a warning in the Programmer's Reference Manual is warranted.
Thanks again for your help.
14
Technical support / Re:XServer comm problems
« on: March 18, 2009, 09:38:43 PM »
Thank you for your prompt reply.
My program does not use either comm port, but does access EEPROM, I believe at initialization only.
I will do some further checking.
My program does not use either comm port, but does access EEPROM, I believe at initialization only.
I will do some further checking.
15
Technical support / XServer comm problems
« on: March 18, 2009, 09:48:47 AM »
When attempting to monitor a fairly complex program running on an MD100-888 after connecting to XServer I get "No Response from Node1" after initial success.
On-Line Monitoring works fine, although very sluggish, when using TLServer.
Similar problem (commexception A0, no response from PLC) when running JAVA applet xhmi1.
Tried changing baud rate to 9600...same result.
Monitoring a very simple program (continuously sampling and displaying all eight ADC inputs) seems to work fine.
On-Line Monitoring works fine, although very sluggish, when using TLServer.
Similar problem (commexception A0, no response from PLC) when running JAVA applet xhmi1.
Tried changing baud rate to 9600...same result.
Monitoring a very simple program (continuously sampling and displaying all eight ADC inputs) seems to work fine.
Pages: [1] 2