Relays for Lesvedome

[pmlogg]

Alan

Yes, when DO2 is connected as normal and the connection to the 12V battery is made, relays 1 and 2 click and their LEDs illuminate.  The LEDs stay illuminated.  When the VM110 is disconnected other than to the computer, selecting each of the outputs causes the led to come on and they go off again when deselected. 

The voltages 0.82 etc. were recorded when the VM110 was only connected to the computer and the relay board was not powered. 

The voltages in the table were made with DO1 and DO2 connected and also DC- on the relay board to Grd on the VM110 and the relay board was powered.  They were switched off and on as per the table column headings.

I'll go now to measure at DO1 and DO2.  I will have to look to see whether the Lesvedome programme allows a choice of which Digital Output is used. I don't think it is something that I set when putting parameters into Lesvedome.

Thanks, Peter

[pmlogg]

Alan

The measurements that you suggested:

DO1 to Grd:  DO1 on = 0.68V  DO1 off = 11.7V

DO2 to Grd:  DO2 on = 0.70V  DO2 off = 8.25V

So DO2 off not as high as DO1 off but still a lot higher than DO2 on.

I looked at Lesvedome and couldn't see any way of selecting which Digital output to use.

Thanks, Peter

[symmetal]

Peter,

Those readings indicate that although the DO1 and DO2 outputs are turning on and off, the output darlington transistor pair driving DO2 output on the VM110 is sinking some current even when turned off, (much more than DO1) such that the opto-isolators on the relay board for relays 1 and 2 are passing about 0.8mA. This appears to be emitting enough light to turn on the relays.

Just to test if it's the VM110 causing the problem disconnect the wire from DO1 and move the wire from DO2 to DO1. Then power it all up and run the tests again. This time when you tell DO1 to turn off and on, relays 1 and 2 should now turn off and on. If they do then the DO2 output on the VM110 is faulty.

If RL1 and RL2 still stay on permanently then the VM110 for some bizarre reason can't drive two relay opto-isolators. Put the wire back to DO2 as normal but leave the DO1 wire disconnected. Remove the wire from IN2- and run the test again telling DO2 to turn off and on. If RL1 now turns off and on there is a problem with driving two relays from one output and it requires more thought.

Alan

Edited June 14, 2019 by symmetal

[pmlogg]

Alan

OK, that's a plan for Friday night.

Many thanks, Peter

[pmlogg]

Hugh and Alan,

I was looking at the Lesvedome documentation just to check about assigning a different Digital Output rather than No. 2 but I came across this paragraph which referred to the Edward Plummer circuit diagramme in the Lesvedome instructions:

"ELK924 [relay] needs to be triggered in "insensitive" mode, (2) reverse-current protection diode D0 prevents the DI4 circuit from triggering ELK924 all the time. 

The relay that is referring to is one on the connection from Digital Input 4 to Digital Output 2.  I initially had that diode drawn in on the basis of the Edward Plummer diagram but you correctly pointed out Hugh that the standard circuit from Charles Harrow does not have a diode, that your working system does not include the diode and that the 0.5 to 1.0V drop caused by the diode might cause a problem. However might wiring in a diode be worth a try just in my variant circuit?

Thanks, Peter

[pmlogg]

Hugh and Alan

Further to my last I've just found Edward Plumer's more detailed explanation of why he deviated from the Charles Harrow circuit:

"My main modifications [from the Charles Harrow circuit] were the inclusion of a motor-speed control board and to alter which triggering mode to use on the ELK boards since some forum users were having problems with the ELK924 triggering all of the time. Here is a post I put on the LesveDome Yahoo group regarding the triggering problem:

The root problem is that the ELK board in "sensitive mode", triggers on a very small current injection into (T-), small enough that the pull-up circuitry in the input section of the 8055 can source this current. Note that the relay boards are powered at 12V and the input of 8055 is only pulled up to 5V. I reasoned that from the ELK ckt point of view, the 5V pull-up actually look "low" enough to to act like the input to the relay board has been pulled down and negatively triggered. ... There are 2 alternative solutions:

(1) Force the relay board to act as a voltage switched device - This was my approach. Ensure that the 8055-Output2 has to pull the boards negative power rail down to GND along with the trigger input. Minor current flowing into 8055-input logic will do nothing because the circuitry in the ELK board is not "grounded".

(2) Shut down the inappropriate current path - This was Joe's approach. The diode between Out2 and In4 only allows current to flow FROM In4 TO Out2. Thus, if Out2 is pulled to 0V, current can flow from In4 to Out2 and be detected by the 8055 as an input signal. However, If Out2 is not enable, the diode prevents current from exiting the 12V circuit of ELK input, into In4, through the pullup resistor, to the 5V level."

 

Perhaps this was a specific issue with the ELK relay boards but might it also be with the one I'm using?

Thanks, Peter

[symmetal]

Peter,

That's a good point Peter. I forgot about the connection from DO2 to DI4. That would most likely be the cause of the problem. With DO2 turning off, the voltage on DO2 should rise to close to the 12V from the relay board (DO1 does as it rises to 11.7V when off) so no current flows through the opto-led to turn on the relay. However the pull up resistors to 5V on DI4 will prevent this from happening fully, so DO2 output only rises to 8V or so allowing the opto-led to stay on by the current flowing into DI4. Putting the diode back between DO2 and DI4 means when the DO2 output turns off and its output rises towards 12V when it passes 6V or so the diode will be reversed biased and prevent current flowing into DI4. DO2 should then rise to near 12V turning off the relays 1 and 2.

I should have spotted this earlier Peter. Sorry about that. Hopefully it should now all work. 

Alan

[pmlogg]

Alan

Thanks for that explanation as I would not have been up to explaining why it could/should work.

As that may be a solution, and I have diodes to hand, I'll try that before doing further testing.

Thanks, Peter

[pmlogg]

Alan and Hugh

In total I've taken out the diode and 3 resistors on the 12+ lines and added the diode onto the IN4 DO2 line and that has sorted that out!

When I power up only the relay board (not individual relays) illuminates.  When in the dome.exe programme I select Output 1 I get motion in one direction and when Outputs 1 and 2 are active I have motion in the other direction.  And that both by direct usb connection and when connected via the Raspberry Pi's virtual usb link.

I'm going to add back in the encoder to check its still doing what it's supposed to do.  I could even try the Hall Switch but I can't see why the changes I've made should help that. 

Annoyingly Fedex has messed me around yet again today.  I'd ordered my 3009 optical sensor from TME for £1.47 plus post plus VAT and it was due to arrive today.  Unfortunately my wife was out and instead of putting the package through the letterbox (it should be pretty small) they took it all the way back to their depot 40 miles away.  Apparently this valuable parcel had to be signed for so I won't see it until Monday!  A similar thing happened to me with parts coming from Mouser in the US - the Bourns connector cable being one of them.  They missed us on the Friday before the bank holiday and took not just the Monday off but Tuesday too, so 2 days crossing the Atlantic then 5 days delay getting across Scotland, hopeless.

I'll not let that spoil the moment though.  So, many many thanks for helping me to get this far, including the diagrams, explanation and fault finding.  Fingers crossed that the two sensors now do their bit - if so I might even manage to get it up and mounted in the Dome for a trial run within the next week.  I will send photos once the components are secured etc.

Thanks

Peter

[symmetal]

Peter,

Well done on getting the relays all working now.

If you want to try the Hall effect switch again try putting a diode between the switch output and DI2 like I suggested a few posts ago. Also include the 10k pull up to +12V. I've repeated the drawing here. It should isolate the 12V switch from the 5V from the VM110 digital inputs, and allow the switch output to rise to 12V when it's off, similar to the function of the diode you put between DO2 and DI4. This may stop the switch from turning on as soon as you connect it to the VM110. Worth a try while you're waiting for Fedex to redeliver your opto-switch. Use one of the diodes you have, the type number isn't important.

Alan

 

Edited June 14, 2019 by symmetal

[pmlogg]

Alan

Thanks for the thumbs up and for the suggestion/diagram for the Hall Switch.  I will definitely give that a try as the Hall Switch is otherwise all mechanically fitted and wired in.

I've just finished wiring in the voltage regulator and testing that the relays and encoder were still working - which thank goodness they are.  It is currently feeding 5V to the Hall Switch and the LED is still on but is dimmer - the 10K is though out of the loom just now but I can easily put it back in.

I'll let you know what happens with that - I'll initially try it at 5V as an experiment before switching it back to 12V.

Thanks

Peter

[pmlogg]

Alan

Diode and Resistor in - Hall Switch working on the 5V supply.  LED off until magnet approaches - then the LED illuminates and Counter 2 adds one to its count - Perfect.

So all seems to be working under Dome.exe but Lesvedome still  isn't happy for some reason.  I'll need to remind myself of the direct quote but essentially it does not slew when told to and disconnects itself.

I've not yet done the uninstall of the most up-to-date Lesvedome to revert to the older.  Perhaps that should be my next step. 

Thanks

Peter

[symmetal]

Peter,

That's great that the diode on the Hall effect switch now makes it work, and on 5V too, another bonus. So all the hardware's now working.  However you now have two spare opto-switches. 

I'm sure Hugh will be able to help you with the Lesvedome software problem you've got.

Alan

[hughgilhespie]

Hi Peter,

Phew!! Well done! And a really good catch from Alan to spot that the DO2 / DI1 connection needed a blocking diode.

I am more than willing to try and help with the Lesvedome software but I should say that my set-up is far from typical in that I don't use relays I use the output signals from the VM110 board to drive a homebrew microprocessor set-up that lets me use stepper motors for the dome and shutter operation. I also use a 64 ppr Bourne encoder to measure my dome position. This gives too many pulses for the Lesvedome software to cope with so I use software to generate a reduced pulse rate that is fed back to the VM110. The other thing worth saying is that the Lesvedome forum and Pierre de Ponthiere, the Lesvedome software author are very helpful. It is also good to read the Lesvedome help files a few times as there is a lot of good information there.

For the Lesvedome software to operate with the VM110 board, as far as I know the only external things needed are these:

relays output signals on DO1 and DO2

position encoder input signals on DI1 and DI5

motor direction signal on DI4

home position switch signal on DI2 - Actually I am not sure this is needed  for testing with the Lesvedome User Interface as its only action  is  to reset  the dome azimuth position to the value defined in the Setup window.

As the relays are now operating as expected, the most likely cause of any remaining problems are from the encoder. On the Setup page of the LesvedomeNet User Interface try setting the Configuration Azimuth Sensor Mode to 'Hole to Hole' and also try varying the Timer interval. I believe the default value is 60 mS, you could try say 20 and 40 mS to see if that helps.

Let us know how you get on.

Regards, Hugh

[pmlogg]

Alan and Hugh

Yes great news indeed - thanks again for all your help.  However if it turns out that the accuracy of the Hall Effect Switch isn't good enough, then I can relatively easily switch to the opto-switch - so I'll keep the 3009 model. 

Inevitably there were going to be wrong turns and bits bought that would be superseded.  The main one is probably the Compute Stick but I can find another use for that I'm sure. Then there was the very cheap encoder and twin-relay board which I really only got for experimentation.  The little 12V motor was a good buy as it has been much easier to bench test with it than anything bigger.  One cheap XLR chassis connector was a bad buy so has been replaced.  An enclosure that I bought for the encoder had not been thought through - fixings on the wrong side and the stainless spring to keep the encoder wheel in close contact is a bit too short/strong. I have a non-stainless one that will do for now.

The connections you've listed Hugh seem correct in the layout.  I will re-test Lesvedome with those settings.  As I wrote last night I've not tried changing the version of Lesvedome yet.  I was confused because the error message came without any sign of the relay clicking first.

That's the priority but also I need to drill for standoffs and mount the components onto the board I've otherwise prepared for them.  I also need to drill/cut the enclosure for the 3 cable entry points:  DB9 for the connection to the Encoder Box, 4-way XLR to the motor and power switches and usb for the power in from the powerbank.  I also need to tidy up the cables, a lot of which can probably be shortened. Oh and also properly fit the 10K resistor and diode which I only did a temporary job on last night.

We have family visiting today but hopefully later on I'll be able to crack on with much of that.

Thanks

Peter

[pmlogg]

Hugh and Allan

A couple of anomalies. 

In K8055_Demo (not Dome Demo as I wrongly wrote before) twice the motor has stuck on, not reacting when I deselected the digital outputs.  had to disconnect the power

In Lesvedome I twice got the motor to react in one direction, but then got stall in the other.  Once I was able to get CW and CCW but when I tried to repeat that success it was back to stall in both directions.  That time when I got both directions but then stall the next the timer interval was set to 20msec.

Thanks

Peter

[symmetal]

Peter,

The motor sticking on is relay 4 not releasing. Keep your multimeter measuring DO1 o/p on the VM110 while you tell K8055_Demo to turn DO1 on and off. See if there is a voltage difference in the off state between the motor turning off  and when it sticks on. Also ensure the ground connection between the relay board and the VM110 has not worked loose causing intermittent operation.

Alan

[pmlogg]

Alan

OK, I'll try that in the morning.  The VM110, Raspberry Pi and Relay board are all now mounted for the enclosure.  Once I shorten as many connecting wires as I can it will look at lot tidier.  That will be an opportunity to check the connections again, although I did a bit of that this evening - no change on the performance though, same issues.

Thanks

Peter

[hughgilhespie]

Hi Peter,

One thing to bear in mind with your testing is that when the Lesvedome software is operating as designed, it will always stop the motor by making Relay 4 inactive before sending a signal to change motor direction via DO2 . After the change direction signal the software then starts the motor again. I think from memory that there is a delay of 75 milliseconds between the commands. Obviously you can't reproduce this timing manually when using the K8055 Demo software but I just wonder if you will get better results using the K8055 Demo software by always stopping the motor before you change its direction and then restarting.  Worth a go trying it this way anyway.

I can't think of any obvious reason why Relay 4 should latch on. Doing the tests suggested by Alan will be useful in finding the cause.

As for the motor stalling, I think you do need to change back to the earlier version of the Lesvedome software. Although the stall feature is useful I think it is probably too sensitive and will only complicate your testing. When everything else is working will be the time to see what happens when you run the latest version.

HTH

Regards, Hugh

[hughgilhespie]

Hi Peter,

On a slightly different topic, if you are not a member of the Lesvedome Yahoo group I urge you to join. It has a lot of very useful information about the Lesvedome system. The link below gets you there.

https://groups.yahoo.com/neo/groups/lesvedome/conversations/messages

There is currently running a very useful discussion on Bourne rotary encoders, see the topic called Gray Code Mode. One of the members, Steve Hennerly, has posted a link to some software he has written that works in conjunction with the Lesvedome User Interface software and measures the actual performance of the rotary encoder in real time. This will be very helpful for your testing. The output screen looks like this.

 

HTH

Regards, Hugh

[pmlogg]

Alan and Hugh

Sorry for the delay in responding - Father's Day activity.  It will be later tonight before I get down to your suggestions.

Other than shortening the cables and changing over from the temporary connections to the test motor and power the boxes are ready for mounting.

This is a picture of the components. By the Encoder box is the magnet ready for mounting.  Out of picture are the test motor and battery. The connectors - usb, DB9 and XLR are fitted but will need to be removed and refitted during the mounting onto the observatory wall.

Thanks, Peter

[pmlogg]

Hit wrong button, here's the image.

[pmlogg]

Alan and Hugh

In the process of doing the suggested testing I've decided that the problem lies with the wireless usb link.  During the testing I found that sometimes the K80055_demo programme was losing its connection with the VM110 and that's when the motor staying on occurred. Why that happene I don't know as the VirtualHere software kept running.

So I tested with the computer connection coming direct from the computer.  The sticking on didn't happen, the K8055_demo programme maintained it's connection.  More importantly Lesvedome User interface successfully commanded CW and CCW rotation.

So, as you wondered previously Hugh, the Raspberry Pi seemed the weak link.  I had just begun typing this when I thought that perhaps it was power so I went back and connected a Y-cable taking power from two of the Pi's USB ports rather than two.  It didn't make any difference.

So that leaves at least 3 possibilities, but one I think unlikely.  One is that there is something about the Raspberry Pi itself, the second is that it is the VirtualHere software, the unlikely one is associated with the free version of VirtualHere which only supports one USB connection.  Perhaps that also effects power from the other ports , i.e. not switching the port on for power or data, but I'm not sure that is possible.

So, my next action is to get in touch with VirtualHere.  Their staff member that I dealt with before was really helpful so hopefully he will be able to tell me.

Thanks, Peter

[symmetal]

Peter,

Didn't know you were using a USB over WiFi connection. Didn't know they existed, as USB data rates are more than Ethernet can handle let alone WiFi. For USB devices that don't send much data it could be feasible, but don't know how VirtualHere recovers with a momentary WiFi signal loss as USB would still be sending data which isn't being received and USB signal timing is rather critical. Not too well if that's what happening.

I assume your problem is just a poor WiFi signal. Are you testing with the PC and Pi close to the router? I personally don't use WiFi for controlling my astro setup anymore as it's just to unreliable. When you say it worked with the computer connection coming direct you mean using an ethernet cable between them, or both wired to the router.

It wouldn't be a Pi power port problem as the USB ports are powered all the time the Pi's powered.

Hope VirtualHere can help you out.

Alan

[pmlogg]

Alan

Unfortunately wireless control at some point in the chain is an absolute necessity due to the design of the original Pulsar dome - or at least it is unless going to a completely different drive system e.g. some have used Exploradome parts and adapted them accordingly. 

The router was quite close during testing and reported an 'excellent' link. When I say direct I mean a usb cable from the main computer to the VM110, by-passing the Raspberry Pi and not using VirtualHere.

Where I started perhaps a year plus ago was with the idea of having a Compute Stick, with a wire connection to the VM110 and  using Remote Desktop from the main computer. I'd thought to just run Lesvedome on the Compute Stick while controlling the mount from the main computer. However I then reckoned that the two Ascom programmes, one running on each computer probably could not interact via POTH. 

An option could be to run all the Ascom software and Lesvedome from the Compute Stick - linking to the Main Computer as described above but then I would still be back to needing a wireless link, this time to the mount, e.g. by a SkyFi?

As the current control to the mount via wired usb from the main computer is working fine I didn't really want to have to disturb that.  So I went back to the idea of a wireless usb hub.  Some used to be marketed but not any more - perhaps they suffered from unacceptable drop outs.  I couldn't find any used ones available that wouldn't produce other problems like powering the hub and then found VirtualHere and a couple of other packages that are supposed to provide a wireless usb link - although I suggest the others use a local computer e.g. the Compute Stick as the remote hub.  It could be that one of those might be more reliable.

Although VirtualHere recommended using the Pi rather than another Windows computer I don't know whether the Compute Stick might for some reason provide a smoother wireless link.  Just swapping the Pi out and the Compute Stick in would be a relatively simple operation but could introduce other issues.

VirtualHere responded quickly to my email (amazing given that I'm using the free version of their software), giving me something to check tonight.  Fingers crossed.

Thanks, Peter