STOP RIGHT NOW, I want that system taken offline, I want you to compile, link and download right now like the rest of us and then see if your small little fix or large change works, then you can put it back online until the next time you have to dis-appoint your clients. How dare you work on live systems, what are you some kind of production engineer with real clients doing real work?
Really nice Peter, really!
My bad, really bad bad, so bad. I'm so bad that I paste in a new word and have the audacity to allow the server free access to it immediately. That's bad.
There seems to be some bug with the jpg but I will look at that some other time.
If you Telnet in you can type DIR or ls or .LIST to have a look at what files are there. Of course you can also setup FileZilla but I have a little "WIZnet" bug in my block send routine which FTP uses rather than the inefficient XTYPE routine which I am using with HTTP GET at present. BLKSEND is very fast but I broke it and it's 4:30 in the morning so it might have to wait until the morning......hmmmm.....maybe later than that.
My bad, really bad bad, so bad. I'm so bad that I paste in a new word and have the audacity to allow the server free access to it immediately. That's bad.
There seems to be some bug with the jpg but I will look at that some other time.
If you Telnet in you can type DIR or ls or .LIST to have a look at what files are there. Of course you can also setup FileZilla but I have a little "WIZnet" bug in my block send routine which FTP uses rather than the inefficient XTYPE routine which I am using with HTTP GET at present. BLKSEND is very fast but I broke it and it's 4:30 in the morning so it might have to wait until the morning......hmmmm.....maybe later than that.
This efficiency could have all been avoided if you would have just got yourself a real Computer Science Degree you know.
Quick question to anyone who's interested in trying this out. What W5200 Prop hardware do you have? I guess it might be the combination of the QuickStart and the W5200 Ethernet board for the QuickStart. I could probably create a hardware header file for this and download a binary to suit but only if someone is going to try this out.
I do have the QuickStart with the W5200 Ethernet board for the QuickStart. It would be great if you created a header for this combo!
Thanks
I've already started a header file for this on Google docs and this is the web document version here. Ideally the code should be compiled on the same board. Are you able to handle that Bob?
To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.
Quick question to anyone who's interested in trying this out. What W5200 Prop hardware do you have? I guess it might be the combination of the QuickStart and the W5200 Ethernet board for the QuickStart. I could probably create a hardware header file for this and download a binary to suit but only if someone is going to try this out.
I have a BOE with an Wiznet WIZ820IO W5200 module on wired like this.
Have you tried loading those files and running it? The only extra definitions you may need are for the LEDs and WIZnet reset and power-down. I think if you don't define them that it will still compile as I have some IFNDEFs in there to cover that but you will need the reset.Have a look at the QuickStart header file I'm working on for some clues.I'm probably a bit too caught-up in an application I'm doing to do much else at the moment but that does mean that all the rough edges have to get tidied up soon. This is one of the advantages of using Tachyon as it is used to roll real-world embedded production grade applications and I make everything but the complete custom application available as OSS. I've been using Forth for this for decades and it's buried in products literally right around the world.
BUILD sequence using up-to-date web documents:
Compile and load Tachyon V2.3 into EEPROM
Load EXTEND.fth into TF
Load QuickStart.fth
Load SDCARD.fth
Load MULTIFAT.fth
An optional BACKUP wouldn't hurt at this stage
Load W5200.fth
Load NETWORK.fth
Rock n Roll
To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.
I, too, am running the QS/WizNet combo. I have the SD and WN pins done and am hunting down a data sheet for the TI RTC chip and will adapt your 79410 code to it.
I update my copies of this code several times a day. For the last 36 hours the MOUNT word generates a reboot, I can do a !SD and then SD's and read card info, but any of the fuel system commands generate a reboot. The EXTEND, SDCARD and MULTIFILE codes go in "as-is" and hardware config is correct as evidenced by corrrect functioning of !SD and SD.
I've already started a header file for this on Google docs and this is the web document version here. Ideally the code should be compiled on the same board. Are you able to handle that Bob?
To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.
Everything loads above except for NETWORK.fth, last symbol output is LED! around line 525? This is on the QuickStart with W5200 "Cowling" instead of a shield I guess for the Prop
UPDATE: LED! is not defined, investigating
UPDATE: LED! should be LED1 as defined in the header. error line 663 in Network.fth, I'm getting the hang of this FORTH stuff.
I, too, am running the QS/WizNet combo. I have the SD and WN pins done and am hunting down a data sheet for the TI RTC chip and will adapt your 79410 code to it.
I update my copies of this code several times a day. For the last 36 hours the MOUNT word generates a reboot, I can do a !SD and then SD's and read card info, but any of the fuel system commands generate a reboot. The EXTEND, SDCARD and MULTIFILE codes go in "as-is" and hardware config is correct as evidenced by corrrect functioning of !SD and SD.
Any ideas?
Hi Brian, good to see you are getting stuck into it, as you do. I have done all the testing on SDHC cards, usually anything 4GB or more so don't use 2GBs, they are getting pretty hard to get anyway. The RTC words are taken care of by by the virtual RTC in EXTEND.fth so you don't have to worry about that yet. Doesn't the QS have a Seiko RTC? I have a Spinneret that I can check the Seiko chip if need be. Did you use the QuickStart header file I've done up? I will comment out the RTC code until it's ready.
That's the way even if the screen capture looks a little cropped (no directory etc). Just in case you are looking for some files I have made the SDCARD folder in the Tachyon Dropbox folder with those test files that I use.
Quick question to anyone who's interested in trying this out. What W5200 Prop hardware do you have? I guess it might be the combination of the QuickStart and the W5200 Ethernet board for the QuickStart. I could probably create a hardware header file for this and download a binary to suit but only if someone is going to try this out.
The SPINNERETTE is also a viable board isn't it?
After I have moved from Germany to Spain again next week and dust has settled a little, I was thinking of giving my Spinnetete a try with TF.
I also have a load of old WIZnet modules with the W5100 - will those work too?
I am seeing the same REBOOT as Brian is on MOUNT on my QS and W5200. Need to check into the actual sdcard I am using.
Thanks
As mentioned it hasn't been tuned for 2GB cards and FAT16 although the low level drivers should work, I just haven't gotten around to checking FAT16, and at this point there probably isn't much point. Have you used all the latest files including the kernel?
To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.
I have used all the latest files. I am at work right now and will not be able to check the sdcard until later this afternoon. Not swhat size it is or if it is even good.
One thing I did notice is that in the QuickStart.fth header on the web page , the LED! word was not defined and NETWORK.fth uses that word. I defined it as you did in the CE1272.fth .
NETWORK.fth loaded correctly after that. That is the point I left it at after seeing the constant reboots on powerup.
I have used all the latest files. I am at work right now and will not be able to check the sdcard until later this afternoon. Not swhat size it is or if it is even good.
One thing I did notice is that in the QuickStart.fth header on the web page , the LED! word was not defined and NETWORK.fth uses that word. I defined it as you did in the CE1272.fth .
NETWORK.fth loaded correctly after that. That is the point I left it at after seeing the constant reboots on powerup.
Thanks for checking that, the -1 LED! basically does the same thing as what !LED does, turn off all the LEDs. However that function is already implemented in !PCB so for this reason I removed the later LED reference from NETWORK. If you still have troubles just disable the autorun simply by giving AUTORUN an invalid address such as AUTORUN NONE and then running BACKUP. Of course you may not be able to get to this stage so the trick is to either comment out the AUTORUN directive at the end of the NETWORK file when it's loaded or invalidate it with AUTORUN NONE BACKUP before you reboot. The system also looks for ^As at the console input during reboot in which case it will ignore the autorun.
Anyway, once it's not caught in a boot loop you can use the Forth words themselves to find out what's going on. Try SD which will init the SD card and report it for starters.
Thanks for checking that, the -1 LED! basically does the same thing as what !LED does, turn off all the LEDs. However that function is already implemented in !PCB so for this reason I removed the later LED reference from NETWORK. If you still have troubles just disable the autorun simply by giving AUTORUN an invalid address such as AUTORUN NONE and then running BACKUP. Of course you may not be able to get to this stage so the trick is to either comment out the AUTORUN directive at the end of the NETWORK file when it's loaded or invalidate it with AUTORUN NONE BACKUP before you reboot. The system also looks for ^As at the console input during reboot in which case it will ignore the autorun.
Anyway, once it's not caught in a boot loop you can use the Forth words themselves to find out what's going on. Try SD which will init the SD card and report it for starters.
Missed that definition, thought LED! was LED1, now I'm cleared up on this. Also I have been using 4 and 8 Gig SD Cards without issue, multiple vendors.
I was using a Kingston microSDHC, Class 4, 8 GB. This card read and MOUNTed fine with the "as-is" load of SDCARD and MULTIFILE 3-4 days ago. 2 days ago the endless reboots started.
I was using a Kingston microSDHC, Class 4, 8 GB. This card read and MOUNTed fine with the "as-is" load of SDCARD and MULTIFILE 3-4 days ago. 2 days ago the endless reboots started.
Hey Brian, obviously there's a problem and so it's important then to make sure that the application doesn't autorun so you can test out and find what the problem is. Either remove the AUTORUN GO statement from the end of NETWORK or else type AUTORUN NONE BACKUP after you have loaded the modules but before you have reset it. Then I would go with the SD word to init and check the SD card itself before I would try mounting the file system.
Has anyone noticed from perusing the source code that there is not an ounce of assembler? It's all written in TF and all running from the one cog. Of course I have added certain SPI functions to the kernel but they still run from the same cog unlike many Spin objects which require another cog just for that function. This was one of the aims of Tachyon, to be fast enough to handle almost all operations without resorting to inline assembly or a variation thereof in a user application or module. I think that this current code certainly reflects that, and despite Forth being "typeless" too
Hey Brian, obviously there's a problem and so it's important then to make sure that the application doesn't autorun so you can test out and find what the problem is. Either remove the AUTORUN GO statement from the end of NETWORK or else type AUTORUN NONE BACKUP after you have loaded the modules but before you have reset it. Then I would go with the SD word to init and check the SD card itself before I would try mounting the file system.
Has anyone noticed from perusing the source code that there is not an ounce of assembler? It's all written in TF and all running from the one cog. Of course I have added certain SPI functions to the kernel but they still run from the same cog unlike many Spin objects which require another cog just for that function. This was one of the aims of Tachyon, to be fast enough to handle almost all operations without resorting to inline assembly or a variation thereof in a user application or module. I think that this current code certainly reflects that, and despite Forth being "typeless" too
Yes, I did notice everthing is in TF but forgot about 1Cog, wow. I would say you have accomplished your goal well Peter. Also I have had 0 errors with SD with every card I have tried as one reference point on my BOE board.
Using the updated Dropbox files Tachyon V23 .spin, and Forth files EXTEND, QuickStart, SDCARD, MULTIFILE, W5200, and NETWORK with the following edits
Tachyon v23 - changed pll to 16 and Xin to 5 MHz
NETWORK - commented out AUTORUN GO, and changed "-1 LED!" to "!LEDS"
I paused after loading MULTIFILE did a BACKUP and tested !SD and SD then MOUNT ... all OK.
I ran an ethernet cable from the wireless router across the living room to my office to the QS Wiznet board. It in turn went via USB to my iMac and ZTerm program. I opened a terminal window inMac OSX and ran telnet and ftp and used Safari to run http. I also checked using a lightweight Telnet client from my iPhone and iPad Air
Its been up and running for 3 hours with only one 'crash' ... literally, my wife's crazy GSD tripped on the ethernet cable and the power plug pulled from the socket on the QS WizNet board.
I have assigned a domain for the Tachyon Forth server on standard ports (80 rather than 81) etc. So there is no need to specify the ip address or the :81 part anymore. tachyonforth.com
EDIT: BTW, there's a 5 minute alarm timeout on the Telnet and FTP sessions which will reboot the server after 5 minutes if it is still connected. If you are on Telnet this is easy to circumvent but I won't tell you how, just look at the source. HTTP GET requests are limited to 1 minute (long long time).
Needed to "wade thru" some faulty SD cards. Now I have purchased some new ones on cyber sale week. Should have more time this weekend to explore more in TACHYON land!
At present even with a RECLAIM of unnecessary dictionary word memory there is not much memory left after a full compile, although it's still plenty to play with or write a small app. So the combination of code, dictionary, file buffers, serial buffer (reclaimed kernel image), networking etc takes up most of the 32K memory. You can claw at least 3K of that back by defining SMALL before you start loading EXTEND. Just type CREATE SMALL and then load EXTEND which will leave out code that is hardly used such as PWM and MCP3208 etc and some more obscure debug words and also including QWORDS but not WORDS.
With a little more time I will move most of the dictionary to SD for those builds that are large enough that they start running out of precious 32K hub memory. I have already experimented with this and this should make around 10K or more available for application code which in my experience is way more than enough, even my current application only needs about 2K or so. When the dictionary is moved to SD it is optimized as one header per 32 bytes so that we get 16 names per sector but if we load in an application serially it will be saved directly to a file before an FLOAD is executed automatically. So the loading can go as fast as it can without having to worry about extra line delays due to slower searches. Kernel words will "cached" so there is no delay there.
I did some stats on length of headers and found that there was an average name length of 8 bytes and a maximum of 19. So 32 bytes is more than enough as each header normally has 4 other bytes as well. There is a vector associated with each header so this vector will be used to look up stack and help comments stored in another file. The byte-code vector implementation is also of great benefit for P2TF as one or two bytes is all that is needed to address the full 128K but more on that as the time draws closer.
My immediate priority is to fix up the BLKSEND as I've stuffed something up there and haven't had time to look at it. Once this is fixed then FTP should be working properly again. DHCP is another thing to do too.
Comments
My bad, really bad bad, so bad. I'm so bad that I paste in a new word and have the audacity to allow the server free access to it immediately. That's bad.
Try these files on the Tachyon IP 58.174.90.227:81
http://58.174.90.227:81/
http://58.174.90.227:81/tachyon.jpg
http://58.174.90.227:81/logon
http://58.174.90.227:81/favicon.ico
http://58.174.90.227:81/EXTEND.FTH
http://58.174.90.227:81/TACHYON.LST
There seems to be some bug with the jpg but I will look at that some other time.
If you Telnet in you can type DIR or ls or .LIST to have a look at what files are there. Of course you can also setup FileZilla but I have a little "WIZnet" bug in my block send routine which FTP uses rather than the inefficient XTYPE routine which I am using with HTTP GET at present. BLKSEND is very fast but I broke it and it's 4:30 in the morning so it might have to wait until the morning......hmmmm.....maybe later than that.
This efficiency could have all been avoided if you would have just got yourself a real Computer Science Degree you know.
I do have the QuickStart with the W5200 Ethernet board for the QuickStart. It would be great if you created a header for this combo!
Thanks
I've already started a header file for this on Google docs and this is the web document version here. Ideally the code should be compiled on the same board. Are you able to handle that Bob?
BUILD sequence using up-to-date web documents:
Compile and load Tachyon V2.3 into EEPROM
Load EXTEND.fth into TF
Load QuickStart.fth
Load SDCARD.fth
Load MULTIFAT.fth
An optional BACKUP wouldn't hurt at this stage
Load W5200.fth
Load NETWORK.fth
Rock n Roll
To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.
Yes, I can. I will continue you this in the morning after I get some sleep!
Thanks
Bob
I have a BOE with an Wiznet WIZ820IO W5200 module on wired like this.
Be happy to troubleshoot.
Need to read the whole post, I also have a quickstart, rebuilding the world now.
Have you tried loading those files and running it? The only extra definitions you may need are for the LEDs and WIZnet reset and power-down. I think if you don't define them that it will still compile as I have some IFNDEFs in there to cover that but you will need the reset.Have a look at the QuickStart header file I'm working on for some clues.I'm probably a bit too caught-up in an application I'm doing to do much else at the moment but that does mean that all the rough edges have to get tidied up soon. This is one of the advantages of using Tachyon as it is used to roll real-world embedded production grade applications and I make everything but the complete custom application available as OSS. I've been using Forth for this for decades and it's buried in products literally right around the world.
BUILD sequence using up-to-date web documents:
Compile and load Tachyon V2.3 into EEPROM
Load EXTEND.fth into TF
Load QuickStart.fth
Load SDCARD.fth
Load MULTIFAT.fth
An optional BACKUP wouldn't hurt at this stage
Load W5200.fth
Load NETWORK.fth
Rock n Roll
To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.
I update my copies of this code several times a day. For the last 36 hours the MOUNT word generates a reboot, I can do a !SD and then SD's and read card info, but any of the fuel system commands generate a reboot. The EXTEND, SDCARD and MULTIFILE codes go in "as-is" and hardware config is correct as evidenced by corrrect functioning of !SD and SD.
Any ideas?
Everything loads above except for NETWORK.fth, last symbol output is LED! around line 525? This is on the QuickStart with W5200 "Cowling" instead of a shield I guess for the Prop
UPDATE: LED! is not defined, investigating
UPDATE: LED! should be LED1 as defined in the header. error line 663 in Network.fth, I'm getting the hang of this FORTH stuff.
: THX ." Thanks Peter" ;
That's the way even if the screen capture looks a little cropped (no directory etc). Just in case you are looking for some files I have made the SDCARD folder in the Tachyon Dropbox folder with those test files that I use.
The SPINNERETTE is also a viable board isn't it?
After I have moved from Germany to Spain again next week and dust has settled a little, I was thinking of giving my Spinnetete a try with TF.
I also have a load of old WIZnet modules with the W5100 - will those work too?
really impressive what you create here
I am seeing the same REBOOT as Brian is on MOUNT on my QS and W5200. Need to check into the actual sdcard I am using.
Thanks
BUILD sequence using up-to-date web documents:
Compile and load Tachyon V2.3 into EEPROM
Load EXTEND.fth into TF
Load QuickStart.fth
Load SDCARD.fth
Load MULTIFAT.fth
An optional BACKUP wouldn't hurt at this stage
Load W5200.fth
Load NETWORK.fth
Rock n Roll
To change your default IP settings look at how it's done in WCOLD in W5200.fth but rather than changing that file just execute the settings interactively as these will not change again, there is no need to do a BACKUP as the settings are written directly into the very top of the 64K EEPROM.
I have used all the latest files. I am at work right now and will not be able to check the sdcard until later this afternoon. Not swhat size it is or if it is even good.
One thing I did notice is that in the QuickStart.fth header on the web page , the LED! word was not defined and NETWORK.fth uses that word. I defined it as you did in the CE1272.fth .
NETWORK.fth loaded correctly after that. That is the point I left it at after seeing the constant reboots on powerup.
[QUOTE
Propeller .:.:--TACHYON--:.:. Forth V23131204.0300
NAMES: $544A...73B4 for 8042 (0507 bytes added)
CODE: $0000...5002 for 12440 (2297 bytes added)
CALLS: 0178 vectors free
RAM: 1096 bytes free
AUTORUN GO
MODULES LOADED:
4709: NETWORK.fth WIZNET NETWORK SERVERS 131023.1500
4086: W5200.fth WIZNET W5200 driver 131107.0000
38C4: MULTIFILE.fth FAT32/16 MultiFile Layer V1.1 131111-0000
3187: SDCARD.fth SD CARD Toolkit - 131114.0000
2FBF: QuickStart.fth QuickStart + W5200 HARDWARE DEFINITIONS 131204.1200
17C0: EXTEND.fth Primary extensions to TACHYON kernel - 131124-0000
*** Tachyon Forth Network and File Server ***][/QUOTE]
Thanks
Bob
Thanks
Bob[/QUOTE]
Thanks for checking that, the -1 LED! basically does the same thing as what !LED does, turn off all the LEDs. However that function is already implemented in !PCB so for this reason I removed the later LED reference from NETWORK. If you still have troubles just disable the autorun simply by giving AUTORUN an invalid address such as AUTORUN NONE and then running BACKUP. Of course you may not be able to get to this stage so the trick is to either comment out the AUTORUN directive at the end of the NETWORK file when it's loaded or invalidate it with AUTORUN NONE BACKUP before you reboot. The system also looks for ^As at the console input during reboot in which case it will ignore the autorun.
Anyway, once it's not caught in a boot loop you can use the Forth words themselves to find out what's going on. Try SD which will init the SD card and report it for starters.
Missed that definition, thought LED! was LED1, now I'm cleared up on this. Also I have been using 4 and 8 Gig SD Cards without issue, multiple vendors.
Hey Brian, obviously there's a problem and so it's important then to make sure that the application doesn't autorun so you can test out and find what the problem is. Either remove the AUTORUN GO statement from the end of NETWORK or else type AUTORUN NONE BACKUP after you have loaded the modules but before you have reset it. Then I would go with the SD word to init and check the SD card itself before I would try mounting the file system.
Has anyone noticed from perusing the source code that there is not an ounce of assembler? It's all written in TF and all running from the one cog. Of course I have added certain SPI functions to the kernel but they still run from the same cog unlike many Spin objects which require another cog just for that function. This was one of the aims of Tachyon, to be fast enough to handle almost all operations without resorting to inline assembly or a variation thereof in a user application or module. I think that this current code certainly reflects that, and despite Forth being "typeless" too
Using the updated Dropbox files Tachyon V23 .spin, and Forth files EXTEND, QuickStart, SDCARD, MULTIFILE, W5200, and NETWORK with the following edits
Tachyon v23 - changed pll to 16 and Xin to 5 MHz
NETWORK - commented out AUTORUN GO, and changed "-1 LED!" to "!LEDS"
I paused after loading MULTIFILE did a BACKUP and tested !SD and SD then MOUNT ... all OK.
I ran an ethernet cable from the wireless router across the living room to my office to the QS Wiznet board. It in turn went via USB to my iMac and ZTerm program. I opened a terminal window inMac OSX and ran telnet and ftp and used Safari to run http. I also checked using a lightweight Telnet client from my iPhone and iPad Air
Its been up and running for 3 hours with only one 'crash' ... literally, my wife's crazy GSD tripped on the ethernet cable and the power plug pulled from the socket on the QS WizNet board.
tachyonforth.com
EDIT: BTW, there's a 5 minute alarm timeout on the Telnet and FTP sessions which will reboot the server after 5 minutes if it is still connected. If you are on Telnet this is easy to circumvent but I won't tell you how, just look at the source. HTTP GET requests are limited to 1 minute (long long time).
Needed to "wade thru" some faulty SD cards. Now I have purchased some new ones on cyber sale week. Should have more time this weekend to explore more in TACHYON land!
Great work Peter. Hurrah!!
Bob
I think that I have found bug in the virtual time code
I am busy right now so I don't have the time to debug and see if the problem lies in .TIME or TIME!
Also, the virtual RTC doesn't seem to be updating the file date/time.
P.S. MY build today went absolutely clean .. I did a COLD on yesterday's build and applied the recently updated files from DropBox substituting QS.FTH
With a little more time I will move most of the dictionary to SD for those builds that are large enough that they start running out of precious 32K hub memory. I have already experimented with this and this should make around 10K or more available for application code which in my experience is way more than enough, even my current application only needs about 2K or so. When the dictionary is moved to SD it is optimized as one header per 32 bytes so that we get 16 names per sector but if we load in an application serially it will be saved directly to a file before an FLOAD is executed automatically. So the loading can go as fast as it can without having to worry about extra line delays due to slower searches. Kernel words will "cached" so there is no delay there.
I did some stats on length of headers and found that there was an average name length of 8 bytes and a maximum of 19. So 32 bytes is more than enough as each header normally has 4 other bytes as well. There is a vector associated with each header so this vector will be used to look up stack and help comments stored in another file. The byte-code vector implementation is also of great benefit for P2TF as one or two bytes is all that is needed to address the full 128K but more on that as the time draws closer.
My immediate priority is to fix up the BLKSEND as I've stuffed something up there and haven't had time to look at it. Once this is fixed then FTP should be working properly again. DHCP is another thing to do too.
Never mind