jbqubit
commented
6 years ago @dtcallcock noted
Ethernet connectivity would be nice for standalone operation. A transparent Ethernet->UART convertor like this would only add about $10 to the board cost and could easily be DNPed. The only reason I can think not to add this is if it's a buggy piece of junk - anyone used one?
@hartytp replied
I did think about that, the reason I decided against it was just the usual feature creep etc., extra bugs etc. My feeling is that it's better just to make an Arduino/Beaglebone/whatever EEM shield and put the ethernet on that.
@dtcallcock
I think the board will be much less likely to be used standalone if you need to faff around with a second EEM (that will also need firmware and debugging). Another issue with things like Beaglebones is that as they run an OS, which means we can't easily put them on the NIST network. I can also imagine a few other EEM boards in a similar vein to this one that would benefit from cheap, simple and robust ethernet connectivity, so if we can find a good solution it could be reused.
@gkasprow
Let's use Ethernet solution we use in uTCA chassis based on Texas Instruments CPU compatible with RUST. @sbourdeauducq will like it. It's a single chip solution.
@gkasprow
The module is similar cost to ADI and Maxim chips that do similar job, but require analog compensation which is painful. In case of troubles with availability we can always develop replacement - the HW part of this module is trivial - just CPU and DC/DC converter, but the FW is considerable effort to develop.
@dtcallcock
Given we don't need fast control and it's unlikely that any physics experiment will ever need to talk to this module, aren't we just using Kasli/Metlino as an expensive and inconvenient Ethernet->UART convertor.
@hartytp said
Re the ethernet thing:
- Generally, I like the UART interface because it's pretty standard, simple and well supported. One can easily covert it to USB or ethernet using readily available adapters and one can use it directly with most micro controllers. We will probably use one of those USB adapters for initial debugging and operation.
- UART is what the Thorlabs chip provides, so it's the least work. If we use UART then the PCB is pretty trivial. Ethernet would be a major increase in complication, which I don't think is justified in this case.
- My assumption is that any lab using this EEM will already have a few Kasli floating around. The reason we put a large FPGA on Kasli was to have plenty of spare IO. So, it's basically no extra cost to run a RJ45 from the DIO_RJ45 board to the Thermostat EEM. This single RJ45 can control both channels independently.
- Another nice use case for the EEM connector UART interface is things like temperature stabilising a Zotino. Here the same Kasli can supply all power and IO needed with a few ribbon cables. That's much nicer than having to have an external ethernet connection IMHO.
- We could provide ethernet as well as UART-via-RJ45 on the front panel, but then it starts to get to be a bit of a mess (plus too much room for users to plug the cable into the wrong connector). Plus, we'd probably need one ethernet adapter per temperature control channel (I don't want to get into the extra overhead involved with multiplexing multiple temperature controllers onto the same ethernet connection).
- The ethernet connection is generally quite complex and could be a large time sink to debug and get working robustly
- I don't want anything on here that needs firmware if at all possible (that's one of the big advantages of the thorlabs IC IMHO). The cost of programming boards at production then debugging and maintaining firmware is just too great for a project this simple in my opinion. That rules out anything based on a rust microprocessor or as far as I'm concerned. We could go for the lantronix or something like that, but it would be a significant increase to the complexity of the project and I just don't see the justification for it.
@dtcallcock said
I think I'm missing something here. Right now, using the core device to intermittently talk to misc non-real time hardware, do logging, and other general housekeeping is very undesirable and unscalable as it directly interferes with running experiments. Having a direct connection from the hardware to a PC running an Artiq slave seems like the right way of doing this and the one that was envisioned from the outset. However it seems that @hartytp is envisioning extra Kaslis being dotted around the lab to handle this kind of thing instead of PCs. Is one picture correct or is it really just a matter of personal preference?
One can easily covert it to USB or ethernet using readily available adapters and one can use it directly with most micro controllers.
If my picture above is correct then I think any piece of hardware where direct connection to a PC is the preferred mode of operation should have the necessary hardware (eg. ethernet) built in. One of the big wins of Sinara for me will be not having to add my own adaptors or micro controllers to things.
I don't want anything on here that needs firmware if at all possible (that's one of the big advantages of the thorlabs IC IMHO). The cost of programming boards at production then debugging and maintaining firmware is just too great for a project this simple in my opinion.
The ethernet to UART convertor I suggested obviously has firmware but, just like the Thorlabs controller it is pre-loaded and hidden from the user (as @sbourdeauducq points out).
The ethernet connection is generally quite complex and could be a large time sink to debug and get working robustly
These convertors are supposedly transparent (like the Ethernet to GPIB convertors we use). I mean if they don't actually work, that's one thing, but if they do then it doesn't seem like any extra work. Does anyone have experience with these? If they are junky then having something equivalent would be a great addition to Sinara in my opinion. In that case I think it should be considered a separate project (albeit one that Thermostat can take advantage of) and we should move it to another thread.
gkasprow
sbourdeauducq
hartytp
dtcallcock
marmeladapk
In #461 there was discussion of adding an Ethernet-to-serial interface to a temperature controller EEM (https://github.com/m-labs/sinara/wiki/Thermostat) proposed by @hartytp. Presently there are 2 EEM carriers (interface boards) in the Sinara ecosystem: Kasli Carrier and VHDCI Carrier. An Ethernet-to-EEM interface would be a third low-cost option for interfacing with EEMs. Let's discuss that possibility in this Issue as it doesn't relate to a specific EEM.