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.


Messages - ccdubs

Pages: 1 2 3 [4] 5 6 ... 8
46
Technical support / Re:MODBUS/Coms issue
« on: December 31, 2010, 05:26:07 PM »
I used SETPROTOCOL 1, 1 as I use MODBUS RTU but I still have the same problem, even now with a different PLC program.

This is the sequence of events:

1) MODBUS is working fine.
2) I depower and repower the PLC and MODBUS doesn't work
3) I turn DIP 4 on and MODBUS doesn't work
4) I depower and repower with DIP 4 on and MODBUS works
5) I turn DIP 4 off and MODBUS still works (this is what I had to do before step 1)

The MODBUS routine in this instance simply writes an incrementing variable to DM[100] (pauses 2s) then reads DM[100] to DM[109]. Interestingly the returned values are a mix of random numbers (DM[100] is correct) which don't match with what I see from the Trilogi online monitoring.


47
Technical support / MODBUS/Coms issue
« on: November 24, 2010, 06:42:36 PM »
I have a strange thing happening where randomly, the T100 PLC will stop communicating with a PC set up as the MODBUS master.

Rebooting the PLC has no effect. If I depower, switch DIP4 on, repower, switch DIP4 off, communications work again.

Does this make any sense?

48
Technical support / Re:RS232 port close time
« on: August 20, 2010, 02:01:44 PM »
Timeout error every time (this is set at 500ms)

49
Technical support / Re:RS232 port close time
« on: August 18, 2010, 04:23:32 PM »
I am only writing to a single DM. The value is a heartbeat that increments with each transmission to allow the PLC to determine if there is a loss of coms with the PC. The timeout for this alarm is set to 60 seconds and the alarm activates every now and then. The PC updates the heartbeat every 10s so it takes 6 consecutive failures.

There is no indication that there is a fault with the PC or SCADA and eventually, the heartbeat will reset. The coms monitor on the PC shows that only the write command fails and it does this for a finite random period, then at some point write coms resumes and runs happily. It looks like during this time reading continues without error (reading polls at 3 seconds and returns 30 DMs).

The SCADA is sequential so a write command shouldn?t be actioned until the read command is finished and there has been a 100ms delay.

50
Technical support / Re:RS232 port close time
« on: August 18, 2010, 12:53:03 PM »
Maybe I have my com port numbers mixed up, I am using the DB9 port with RS232. NOT RS485.

The master is a PC running DAQFactory. Due to the way the sequences are written, the situation can randomly occur where a write is commanded very shortly after a read. I have put in a delay of 100ms before the write command. While this has improved things I still periodically get a write error.
 

51
Technical support / RS232 port close time
« on: August 18, 2010, 02:41:59 AM »
I have a F1616 PLC that is polled via modbus on COM1 (RS232) from a master device. The master reads and writes data.

Is there a recomended delay between a read and the subsequent write commands(and vice versa). I have the problem where I sometimes fail to write and I assume it is because there isn't a long enough delay.

52
Technical support / Re:F1616 Relay Outputs
« on: May 29, 2010, 01:29:44 PM »
Understood. This should be in the user manual as it could quite easily be overlooked.

53
Technical support / F1616 Relay Outputs
« on: May 28, 2010, 02:52:22 PM »
What are the 24Vdc current ratings of each relay output on the F1616 PLC.

The manual says 5A @24V/120VAC. I assume 24V is DC.

If the rating is 5A each how does the board conduct a maximum of 60A (5 A *12 relays) safely? There doesn't appear to be any significant conductors and the COM pin is quite small.

Can you also confirm that there are no issues connecting +24Vdc to the COM terminal of the relay DO's.

Many thanks.

54
Technical support / Re:F2424 Frequency measurement averaging
« on: April 06, 2010, 12:59:29 PM »
One of my favourite ways of averaging is a method that doesn't use multiple memory values and is really useful when wanting long averaging times or very fast processing.

The formula is:

NewAvg = LastAvg + (CurrentVal - LastAvg )/Constant

The constant value determines the rate of averaging. The higher the number the longer the average. I guess this is more accurately a smoothing function but can work very well depending on the application.

55
Technical support / Connecting T100MD888 to microcontroller
« on: November 26, 2009, 11:25:14 AM »
I want to be able to communicate between a T100MD888 to a single PICAXE microcontroller via RS485.

Does anyone have experience with doing this or can perhaps give me some idea of how this would be done?

Cheers

56
Technical support / Re:Com 1 Issue
« on: July 27, 2009, 10:00:25 PM »
OK thanks.

In the mean time is there anything else I should look at replacing? Will testing that RS485 works prove anything?

57
Technical support / Re:Com 1 Issue
« on: July 25, 2009, 05:50:52 PM »
Well I finally got around to trying this but it made no difference.

Any other suggestions?

I thought I would try the 485 port as I found my serial port driver had the ability to switch over to 485. However I have no idea which pins to use on the DB9 socket. Is there any standard for this?

58
Technical support / Re:Com 1 Issue
« on: April 27, 2009, 12:58:39 PM »
Thanks support.

I don't have a PLC in front of me, are the locations of these compontents obvious? I wouldn't want to replace the wrong component if there is more than 1.

Thanks.

59
Technical support / Com 1 Issue
« on: April 25, 2009, 09:59:40 PM »
Hi,

I'm not exactly sure how but I think I may have damaged com 1 on a T100MD. I think an overvoltage may have occured.

What components should I try changing to get it working. I have another "spare" PLC that I can canabalise.

Thanks

60
Technical support / Re:Output State on Power Off
« on: April 19, 2009, 10:56:25 PM »
Hi Support,

Regarding this thread from over a year ago, I notice in the latest batch of PLC's that one of the referred chips (ULN2003A/ULN2803A) has been replaced by a different chip.

Is the disconnection of pin #9 still valid?

Pages: 1 2 3 [4] 5 6 ... 8